Systems and methods for automatic detection of gig-economy activitysystems and methods for automatic detection of gig-economy activity

ABSTRACT

Systems and methods relating to improving the experience of gig-economy workers are disclosed, with particular reference to gig-economy work involving vehicle use. Such systems and methods include automatically monitoring and evaluating activities such as driving during performance of gigs, as well as providing recommendations based thereupon. Gig-related activities may be automatically detected based upon data provided by a mobile device associated with the gig-economy worker, thereby automatically generating a record of such activities for the worker. Telematics data indicative of movement of a vehicle may be collected and analyzed to detect gig-economy activities. During or after performance of gig-economy work, data automatically collected may be used to generate and present recommendations or education points to the gig-economy worker.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.17/170,741 (filed Feb. 8, 2021), which claims the benefit of U.S.Provisional Application No. 62/971,519 (filed Feb. 7, 2020) and U.S.Provisional Application No. 63/021,360 (filed May 7, 2020), the entiretyof each of which is incorporated by reference herein.

TECHNICAL FIELD

The present disclosure generally relates to systems and methods fordetecting, monitoring, and optimizing gig-economy work for gig-economyworkers, particularly with respect to gigs involving vehicles ortransportation.

BACKGROUND

Gig-economy work has grown significantly in recent years due to thecoordination power of mobile computing networks. Millions of gig-economyworkers provide a broad array of gig-economy services, such as on-demandtransportation services (e.g., ridesharing or transportation networkcompany (“TNC”) services), distributed goods delivery services,project-based home and office assistance services, and other services onan ad hoc or transactional basis.

The rapid increase in both supply and demand for such services has drawnin many new service providers, but information resources are lacking.The differences between traditional work and gig-economy work have leftgaps in areas such as risk assessment and gig optimization. This resultsin an increased record-keeping burden on individual gig-economy workersto attempt to track their own activities. Additionally, by thedistributed nature of gig-economy work, the supply of gig-economy is theresult of many unrelated individual decisions, making it difficult forindividual gig-economy workers to determine whether it is worthwhile tooffer their services at any given time.

Certain costs with significant impacts on gig-economy work profitabilityare also unobservable by even the most sophisticated gig-economyworkers. For example, on-demand transportation services are typically inhigh demand at times and places where risk levels of vehicle accidentsare elevated (e.g., during inclement weather, in crowded businessdistricts, and late at night on weekends). However, risk levelsassociated with on-demand transportation gigs may not be directlyobservable. Thus, gig-economy workers are left without much-neededinformation relating to costs of providing gig services relative to therevenue that may be obtained from offering such services. Thus,inefficient use of gig-economy worker effort results from a lack ofrelevant data. Conventional techniques may have other drawbacks as well.

SUMMARY

The present embodiments relate to, inter alia, detecting, monitoring,and optimizing gig-economy work based upon data associated with aplurality of gig-economy workers and relating to a plurality of gigsperformed by such gig-economy workers. Additional, fewer, or alternativefeatures described herein below may be included in some aspects.

In one aspect, a computer-implemented method for monitoring andevaluating gig-economy work (e.g., commercial driving activity) may beprovided. The method may include, via one or more processors, servers,transceivers, and/or sensors, (i) receiving (and/or generating)availability data corresponding to a gig-economy worker; (ii) responsiveto receiving the availability data, collecting a set of data indicativeof one or more gig-related behaviors (e.g., driving behaviors) of thegig-economy worker; (iii) determining a risk score for each gig-relatedbehavior indicated in the set of data; and/or (iv) determining agig-economy worker profile (e.g., a commercial driving profile)corresponding to the gig-economy worker by evaluating each risk score.The method may include additional, less, or alternate actions, includingthose discussed elsewhere herein.

In another aspect, a computer-implemented method for detectinggig-economy work (e.g., commercial driving activity) may be provided.The method may include, via one or more processors, servers,transceivers, and/or sensors, (i) receiving (and/or generating) movementdata representing movement (e.g., movement of a vehicle) associated witha gig-economy worker; (ii) responsive to receiving the movement data,determining likelihoods that portions of the movement data areattributable to gig-economy work (e.g., commercial driving activities)based upon the movement data; and/or (iii) determining an aspect of aninsurance policy for the gig-economy work or the gig-economy worker(e.g., insurance for a vehicle) based upon the likelihoods. The methodmay include additional, less, or alternate actions, including thosediscussed elsewhere herein.

In yet another aspect, a computer-implemented method for optimizinggig-economy work (e.g., commercial driving activity) may be provided.The method may include, via one or more processors, servers,transceivers, and/or sensors, (i) receiving, at one or more processors,one or more gig optimization criteria indicating one or more outcome gigmetrics to optimize; (ii) obtaining condition data indicating aplurality of conditional values for gig metrics; (iii) selecting one ormore gig-economy data models associated with the one or more outcome gigmetrics; (iv) generating one or more gig optimization recommendationsassociated with the one or more gig optimization criteria by applying atleast some of the condition data to the one or more gig-economy datamodels; and/or (v) causing at least one of the one or more gigoptimization recommendations to be presented to a gig-economy worker bya display of a mobile computing device associated with the gig-economyworker. The method may include additional, less, or alternate actions,including those discussed elsewhere herein.

In a still a further aspect, a computer-implemented method forgenerating a transferable token for a gig-economy worker may beprovided. Generating such a transferable token may include: (1)receiving data representing at least one of an activity, a behavior or awork of the gig-economy worker; (2) responsive to receipt of the data,determining at least one of a risk level or a risk profile for thegig-economy worker based upon the data; (3) forming a transferable tokenthat includes the at least one of the risk level or the risk profile;and/or (4) when requested by a third party, providing the transferabletoken to the third party. The transferable token may be used by thethird party to offer a new or updated policy, service, agreement, oraccount. The method may include additional, less, or alternate actions,including those discussed elsewhere herein.

In another aspect, a computer system for displaying targetedrecommendations for transportation network trips may be provided. Thecomputer system may comprise a transceiver, one or more memories, anelectronic display disposed within a vehicle, and one or more processorsinterfacing with the transceiver, the one or more memories, and theelectronic display. The one or more processors may be configured toreceive availability data corresponding to a gig-economy worker andenvironmental data associated with an environment of the vehicle;determine a targeted recommendation based upon the environmental data;and/or cause the electronic display to display the targetedrecommendation. The system may be configured to have additional, less,or alternate functionality, including that discussed elsewhere herein.

In another aspect, a computer-implemented method for displaying targetedrecommendations for transportation network trips may be provided. Themethod may comprise (1) receiving availability data corresponding to agig-economy worker and environmental data associated with an environmentof the vehicle; (2) determining a targeted recommendation based upon theenvironmental data; and/or (3) displaying the targeted recommendation onan electronic display disposed within the vehicle. The method mayinclude additional, less, or alternate actions, including thosediscussed elsewhere herein.

In another embodiment, a computer readable storage medium comprisingnon-transitory computer readable instructions stored thereon fordisplaying targeted recommendations for transportation network trips maybe provided. The instructions when executed on one or more processorsmay cause the one or more processors to receive availability datacorresponding to a gig-economy worker and environmental data associatedwith an environment of a vehicle; determine a targeted recommendationbased upon the environmental data; and/or cause an electronic displaydisposed within the vehicle to display the targeted recommendation. Theinstructions may direct additional, less, or alternate functionality,including that discussed elsewhere herein.

According to another aspect, methods of coordinating or mobilizinggig-economy services may be provided. Such methods may include, via oneor more processors, servers, and/or transceivers, (i) obtaining anindication of a triggering event associated with an elevated level ofdemand for a type of gig-economy service; (ii) generating a demandprofile including parameters indicating a demand quantity of the type ofgig-economy service; (iii) communicating demand data associated with thedemand profile to one or more gig-economy platforms via correspondingapplication programming interfaces (APIs) of the one or more gig-economyplatforms; (iv) receiving availability data regarding availability of aplurality of gig-economy workers for the type of gig-economy servicebased upon the demand profile; and/or (v) coordinating performance ofthe type of gig-economy service by at least some of the plurality ofgig-economy workers for at least some of a plurality of gig-economyservice consumers. The plurality of gig-economy service consumers may beidentified based upon an association between the gig-economy serviceconsumers and the elevated level of demand. In some embodiments,coordinating performance of the type of gig-economy service may includesending alerts to inactive gig-economy workers to indicate the elevatedlevel of demand.

Systems or computer-readable media storing instructions for implementingall or part of the methods described above may also be provided in someaspects. Systems for implementing such methods may include one or moreof the following: a mobile computing device, an on-board computer of avehicle, a remote server, one or more sensors, one or more communicationmodules configured to communicate wirelessly via radio links, radiofrequency links, and/or wireless communication channels, and/or one ormore program memories coupled to one or more processors of any suchcomputing devices or servers. Such program memories may storeinstructions to cause the one or more processors to implement part orall of the method described above.

BRIEF DESCRIPTION OF DRAWINGS

Advantages will become more apparent to those skilled in the art fromthe following description of the preferred embodiments which have beenshown and described by way of illustration. As will be realized, thepresent embodiments may be capable of other and different embodiments,and their details are capable of modification in various respects.Accordingly, the drawings and description are to be regarded asillustrative in nature and not as restrictive.

The Figures described below depict various aspects of the applications,methods, and systems disclosed herein. It should be understood that eachFigure depicts an embodiment of a particular aspect of the disclosedapplications, systems and methods, and that each of the Figures isintended to accord with one or more possible embodiments thereof.Furthermore, wherever possible, the following description refers to thereference numerals included in the following Figures, in which featuresdepicted in multiple Figures are designated with consistent referencenumerals.

FIG. 1A illustrates a block diagram of an exemplary gig-economy systemfor facilitating and/or monitoring gig-economy work;

FIG. 1B illustrates a block diagram of an exemplary single-platformgig-economy system for facilitating and/or monitoring gig-economy workassociated with a single gig-economy platform;

FIG. 2 illustrates a block diagram of an exemplary mobile computingdevice;

FIG. 3 illustrates a flow diagram of an exemplary gig performancemethod;

FIG. 4 illustrates a flow diagram of an exemplary gig-economy drivingmonitoring method;

FIG. 5 illustrates a flow diagram of an exemplary gig-economy drivingdata collection method;

FIG. 6 illustrates a flow diagram of an exemplary gig-economy drivingeducation point method;

FIG. 7 illustrates a flow diagram of an exemplary automatic gig-economyactivity identification method;

FIG. 8 illustrates a flow diagram of an exemplary gig-economy data modelgeneration method;

FIG. 9 illustrates a flow diagram of an exemplary optimizationrecommendation generation method;

FIG. 10 illustrates a flow diagram of an exemplary real-timeoptimization recommendation generation method;

FIG. 11A illustrates a block diagram of an exemplary computer system forgenerating and applying transferable token generation;

FIG. 11B illustrates a flow diagram of an exemplary transferable tokengeneration and application method;

FIG. 12A illustrates a flow diagram of an exemplary targetedrecommendation method;

FIG. 12B illustrates a block diagram of an exemplary computer system forfacilitating targeted recommendation display for transportation networktrips;

FIG. 12C illustrates a block diagram of another exemplary computersystem for facilitating targeted recommendation display fortransportation network trips;

FIG. 12D illustrate a flow diagram depicting an exemplarycomputer-implemented method corresponding to various embodiments of thepresent disclosure; and

FIG. 13 illustrates a flow diagram of an exemplary computer-implementedmethod for coordination and mobilization method for providinggig-economy services to gig-economy service consumers during times ofelevated demand.

The Figures depict embodiments for purposes of illustration only. Oneskilled in the art will readily recognize from the following discussionthat additional, and/or alternative embodiments of the systems andmethods illustrated herein may be employed without departing from theprinciples of the invention described herein.

DETAILED DESCRIPTION

Gig-economy work currently suffers from a lack of available data uponwhich gig-economy workers may act to optimize their efforts. In order toprovide accurate, timely, and actionable information, the techniquesdisclosed herein generally describe collecting and evaluatinggig-related data to provide new information to gig-economy workers. Withthe authorization of gig-economy workers, the gig-related data may beautomatically collected from computing devices (e.g., smartphones,mobile devices, wearables, vehicle sensors, and/or home sensors)associated with gig-economy workers using sensors installed therein orconnected thereto. Thus, data regarding gig-economy work performance(e.g., hours, locations, profitability) may be collected and evaluatedto provide records and recommendations for improving gig-economy work.

Such recommendations may include recommendations to reduce risk orincrease the quality of gig-economy work at particular locations andtimes for particular gig-economy workers. Thus, customizedrecommendations may be generated and presented to gig-economy workers.Some such recommendations may include or be based upon criteria that areunobservable to gig-economy workers, such as risks (and associatedexpected values of losses) related to gigs. In some embodiments, giginsurance policies covering gig-economy work by gig-economy workers maybe offered or used as a point of comparison for recommendations (e.g.,to provide gig-economy workers estimates of cost differentials betweengigs with different risk levels).

As used herein, the term “gig-economy work” means work performed by agig-economy worker on a transactional basis that is mediated by agig-economy platform that connects workers with customers for theprovision of specific tasks or projects. Such gig-economy work mayinclude on-demand or scheduled services, such as on-demandtransportation, product delivery, defined scope office work, homeproject assistance, moving assistance, or outpatient medical services.As used herein, the term “gig-economy worker” means a worker engaged inthe gig economy to perform gig-economy work for customers on a gigbasis.

As used herein, the term “gig” means a specifically defined task,service, project, or activity performed on a predefined basis for theparticular gig through a gig-economy platform. Example gigs includevehicle transportation between specified locations, delivery of aspecified amount of goods to specified locations, installation ofspecified equipment at a specified location at a scheduled time, orremote on-demand diagnosis of a medical condition. As used herein, theterm “gig-economy platform” means a digital platform operated by anetworked computer system configured to match requests for performanceof gigs by customers with offers to perform gigs by gig-economy workers.

Exemplary Gig-Economy System

FIG. 1A illustrates a block diagram of an exemplary gig-economy system100 on which the exemplary computer-based methods described herein maybe implemented. The high-level architecture may include both hardwareand software applications, as well as various data communicationschannels for communicating data between the various hardware andsoftware components. The gig-economy system 100 may be roughly dividedinto front-end components 2 and back-end components 4. The front-endcomponents 2 may be associated with gig-economy workers and customersand may be configured to receive, generate, obtain, process, or presentdata regarding gig-economy work, including customer demand for servicesand worker availability to perform services. The back-end components 4may be associated with gig-economy platforms providers and other dataproviders or consumers and may be configured to obtain and processgig-related data from the front-end components 2 in order to facilitate,monitor, manage, direct, aggregate, or optimize performance ofgig-economy work.

In some embodiments of the system 100, the front-end components 2 maycommunicate with the back-end components 4 via a network 3. Variousmobile computing devices 110 (discussed in further detail below) maycommunicate with the back-end components 4 via the network 3 to allowthe back-end components 4 to match gig-economy workers with customers,monitor gig-economy work tasks and projects, process payment forgig-economy work performed, and/or record relevant details regardinggig-economy work. The back-end components 4 may use one or more servers40 to receive data from the front-end components 2, store the receiveddata, process the received data, and/or communicate informationassociated with the received or processed data. Some embodiments mayinclude fewer, additional, or alternative components.

The front-end components 2 may include various computing devicesconfigured to generate, process, or present information associated withthe gig-economy work to gig-economy workers, customers, and additionalparticipants. With respect to gig-economy workers, the front-endcomponents 2 may include one or more vehicles 10 having on-boardcomputers 11, user mobile devices 12, and/or wearable computing devices13, all associated with a gig-economy worker 17. A plurality ofadditional vehicles 14 (which may include additional on-board computers,not shown) and additional mobile devices 15 may be associated with aplurality of additional gig-economy workers 16. Each vehicle 10, 14,mobile device 12, 15, and wearable 13 may have one or more sensors,including one or more cameras, audio devices, or other recordingdevices, for generating sensor data, image and audio data, and/or otherdata.

In some embodiments, autonomous devices 30 may also act as gig-economyworkers or may take actions in conjunction with gig-economy workers 16or 17 to provide gig-economy services to customers by performing gigs inwhole or part. For example, an autonomous vehicle may deliver a shipmentof equipment to a location on a street near a customer office, but agig-economy worker 17 may be needed to remove the equipment from theautonomous vehicle and install the equipment within the customer office.

The vehicle 10 may be a personal vehicle associated with the gig-economyworker 17, such as an owned or leased vehicle. The vehicle 10 maysimilarly be a rental vehicle or a vehicle-share vehicle used by thegig-economy worker 17. The vehicle may be any type of powered orunpowered vehicle used by the user for transportation. Over time, thegig-economy worker 17 may make a plurality of trips between variouslocations using various vehicles 10, which may include gig-related tripsand personal trips.

Information regarding at least some such trips may be generated,collected, transmitted, or stored by one or more mobile computingdevices 110 associated with the vehicle 10 or the gig-economy worker 17,such as an on-board computer 11, a user mobile device 12, or a wearablecomputing device 13. The on-board computer 11A may be afactory-installed or aftermarket computer installed within the vehicle10 to perform monitoring, control, or other functions. The on-boardcomputer 11A may be configured to provide general vehicle management andcontrol, or it may be configured for a specific purpose, such asmonitoring vehicle usage or recording data regarding vehicle operation.The on-board computer 11A may interface with the one or more sensorswithin the vehicle 10 to collect data regarding vehicle movement oroperation.

The user mobile device 12 may include general-purpose or special-purposecomputing devices used by the user and designed for portability, such asa smart phone, a laptop computer, a notebook computer, a tabletcomputer, or other computing devices associated with the gig-economyworker 17. The user mobile device 12 may include one or moreapplications, programs, or routines configured to monitor usertransportation, as well as generating an interface for presentinginformation to the user and receiving information from the user.

The wearable computing device 13 may include general-purpose orspecial-purpose computing devices designed to be worn by the user, suchas smart watches, smart glasses, fitness trackers, or other similardevices. The wearable computing device 13 may be configured to operateindependently or may require a communication connection with a usermobile device 12 for some or all features.

In some embodiments, additional sensors, transceivers, or computingdevices in the operating environment of the vehicle 10 may collect orprovide additional information. For example, infrastructure components(not shown) installed in various environments may provide informationregarding vehicle location or local conditions (e.g., weather or trafficconditions).

The front-end components 2 may further include additional vehicles 14associated with the additional gig-economy workers 16. Such additionalvehicles 14 may include traditional, semi-autonomous, or autonomousvehicles not currently being used by the user, such as personal vehiclesof others, commercial vehicles, or vehicle-share vehicles. Some suchadditional vehicles 14 may include or be associated with addition mobiledevices 15, which may be on-board computers or mobile devices similar tothose discussed above.

These additional mobile devices 15 may be communicatively connected tosensors or other components within the additional vehicles 14, to otheradditional vehicles 14 or the vehicle 10, to infrastructure components,to other transportation components, or to the network 3. For example,the additional mobile devices 15 may be configured to implementvehicle-to-vehicle or vehicle-to-infrastructure communication, which mayinclude communication with the computing devices associated with thevehicle 10. The additional vehicles 14 and the additional mobile devices15 may be associated with the additional gig-economy workers 16, who maybe other users of the system 100.

With respect to customers, the front-end components 2 may include aplurality of customer computing devices 20 and/or connected home devices22 associated with a plurality of customers 21. The customers 21 may usethe customer computing devices 20 or connected home devices 22 torequest gig-economy services, specify details regarding such gigs,confirm gigs, or initiate payment associated with gigs. In someembodiments, the connected home devices 22 may be configured toautomatically obtain gig-economy services by requesting gigs beperformed when certain conditions are determined to have been met (e.g.,replacing air filters periodically, scheduling HVAC routine maintenance,scheduling cleaning services, or repair of malfunctioning components ofa smart home system). Thus, connected home devices 22 may communicatewith gig-economy platforms via the network 3 to obtain gig-economyservices in response to the occurrence of triggering conditions, whichan associated customer 21 may have set or authorized in advance.

In some embodiments, autonomous devices 30 may similarly operate ascustomers to obtain gig-economy services, such as by requestingperformance of maintenance gigs (e.g., clearing sensor blockage,replacing sensors, fueling, inflating tires, cleaning the vehicleinterior or exterior, or other services). For example, an autonomousvehicle may obtain cleaning of a passenger compartment orclearing/repair of a blocked sensor during ongoing operation providingautonomous transportation service.

In some embodiments, the front-end components 2 may further includeadditional participant computing devices 50 associated with additionalparticipants 51 to interact with other components of the gig-economysystem 100. Such additional participants 51 may be associated with dataproviders or consumers, such as owners of autonomous devices 30,traditional service providers, advertising or marketing services, ormanagement service providers. The additional participants 51 may obtaininformation regarding gig-economy work and provide or offer relatedservices to customers 21 or gig-economy workers 16 and 17. For example,moving equipment rental facilities may offer equipment rental for gigs,which may be provided to gig-economy workers 16 and 17 through a userinterface associated with the server 40 or with a gig-economy platform.

In some embodiments, some of the front-end components 2 may generate orcollect telematics or other data, which telematics data may beassociated with gigs or may be used for comparison of gig and non-gigconditions. The telematics data may be communicated to the server 40 orother back-end components 4 via the network 3.

The various computing devices of the front-end components 2 maycommunicate with the back-end components 4 via wired or wirelessconnections to the network 3. The network 3 may be a proprietarynetwork, a secure public internet, a virtual private network or someother type of network, such as dedicated access lines, plain ordinarytelephone lines, satellite links, cellular data networks, combinationsof these. The network 3 may include one or more radio frequencycommunication links, such as wireless communication links with mobilecomputing devices 110, such as the on-board computer 11, user mobiledevice 12, wearable computing device 13, additional mobile devices 15,customer computing devices 20, connected home devices 22, autonomousdevices 30, or additional participant computing devices 50. The network3 may also include other wired or wireless communication links withother mobile computing devices 110 or other computing devices. Where thenetwork 3 may include the Internet, and data communications may takeplace over the network 3 via an Internet communication protocol.

The back-end components 4 may include one or more servers 40 configuredto implement part or all of the gig-economy-related processes describedherein. Each server 40 may include one or more computer processorsadapted and configured to execute various software applications andcomponents of the gig-economy system 100, in addition to other softwareapplications. The server 40 may further include a database 46, which maybe adapted to store data related to gigs associated with a plurality ofusers. Such data may include data related to gig-workers, customers, gigperformance, or conditions during gig performance, as discussedelsewhere herein, which data may be collected by or uploaded to theserver 40 via the network 3. The server 40 may access data stored in thedatabase 46 or external data sources when executing various functionsand tasks associated with the methods discussed elsewhere herein.

The server 40 may have a controller 55 that is operatively connected tothe database 46 via a link 56. It should be noted that, while not shown,additional databases may be linked to the controller 55 in a knownmanner. For example, separate databases may be used for various types ofinformation, such as user profiles, gig record data, current conditiondata, or gig-economy data models. Additional databases (not shown) maybe communicatively connected to the server 40 via the network 3, such asdatabases maintained by third parties (e.g., weather, construction, orroad network databases). The controller 55 may include a program memory60, a processor 62 (which may be called a microcontroller or amicroprocessor), a random-access memory (RAM) 64, and an input/output(I/O) circuit 66, all of which may be interconnected via an address/databus 65.

It should be appreciated that although only one processor 62 is shown,the controller 55 may include multiple processors 62. Similarly, thememory of the controller 55 may include multiple RAMs 64 and multipleprogram memories 60. Although the I/O circuit 66 is shown as a singleblock, it should be appreciated that the I/O circuit 66 may include anumber of different types of I/O circuits. The RAM 64 and programmemories 60 may be implemented as semiconductor memories, magneticallyreadable memories, or optically readable memories, for example. Thecontroller 55 may also be operatively connected to the network 3 via alink 35.

The server 40 may further include a number of software applicationsstored in a program memory 60. The various software applications on theserver 40 may include one or more software applications for monitoring,predicting, facilitating, supporting, or optimizing gig-economyactivities. Such software applications may include a classifier 53configured to classify observed activity data as being eithergig-related or not gig-related, as well as machine-learning models 54trained and used for such classification, as discussed further below.The various software applications may be executed on the same computerprocessor or on different computer processors.

The back-end components 4 may further include one or more additionalservers providing information relating to aspects of gig-economy work.These additional servers may be configured to communicate with theserver 40 via the network 3 via a link 38, and these additional serversmay include an account server 41, a transaction server 42, a digital mapserver 43, a task management server 44, and/or a fleet management server45. Information regarding availability or performance of gig-economytasks or projects may be stored in databases associated with the variousadditional servers 41-45, which data may be accessed as part of themethods described herein. In some embodiments, additional or alternativeservers may be used to store information relevant to gig-economy work,such as weather conditions or insurance policies.

The account server 41 may maintain a plurality of user accountsassociated with gig-economy workers 16 and 17, customers 21, oradditional participants 51. In some embodiments, the account server 41may be used to store user profiles for such users, which may beassociated with various services, such as telecommunications services,financial services, insurance policies, or gig-economy services. Thetransaction server 42 may process and record financial transactionsrelated to gig-economy work, such as by facilitating payments throughelectronic transfer of funds.

The digital map server 43 may store geocoded map data regardinglocations and transit pathways through geographic areas, which map datamay be used to determine effective distances or travel times betweenlocations, as well as for determining optimal or alternative routes. Insome embodiments, the digital map server 43 may provide real-time orhistorical traffic data relating to one or more route segments withinthe geographic area, which may include indications of trafficcongestion, traffic flow, construction, lane closures, road closures,accidents, blockages, or other traffic-related conditions.

The servers 44 and 45 may be associated with gig-economy platforms andconfigured to match gig-economy workers 16 and 17 with customers forgigs, track gig performance, and manage payment. The task managementserver 44 may process gig-related data relating to gig tasks orprojects, while the fleet management server 45 may process workerinformation to determine locations of available gig-economy workers 16and 17. In some embodiments, the task management server 44 or the fleetmanagement server 45 may communicate with the digital map server 43 toobtain map data relevant to gigs.

Although the gig-economy system 100 is shown to include one or a limitednumber of the various front-end components 2 and of the back-endcomponents 4, it should be understood that different numbers of any oreach of these components may be utilized in various embodiments.Furthermore, the database storage or processing performed by the one ormore servers 40 and/or additional servers 41-45 may be distributed amonga plurality of servers in an arrangement known as “cloud computing.”This configuration may provide various advantages, such as enabling nearreal-time uploads and downloads of information, as well as providingadditional computing resources needed to handle the monitoring,matching, modeling, and optimization tasks described herein. This may inturn support a thin-client embodiment of some computing devices of thefront-end components 2, such as some mobile computing devices 110.

FIG. 1B illustrates a block diagram of an exemplary single-platformgig-economy system 150 for facilitating and/or monitoring gig-economywork associated with a single gig-economy platform. The single-platformgig-economy system 150 may operate in conjunction with other gig-economyplatforms as part of the gig-economy system 100, with each gig-economyplatform communicating with the front-end components 2 via the network3.

As illustrated, an on-demand services network platform 70 iscommunicatively connected to a plurality of computing devices via thenetwork 3 to facilitate gig-economy work associated with the gig-economyplatform. Thus, the on-demand services network platform 70 may beconnected to the user mobile device 12 associated with the gig-economyworker 17, additional mobile devices 15 associated with additionalgig-economy workers 16, autonomous devices 30, connected home devices22, and customer computing devices 20 associated with customers 21 viathe network 3.

The on-demand services network platform 70 is configured with variousfunctions 71-74 to obtain user data via the network 3, match gig demandwith gig supply, monitor performance, and handle payment. Thus, theaccounts function 71 may be configured to create, modify, and maintainuser accounts associated with users of the platform. The accountsfunction 71 may also maintain records of completed gigs associated witheach user. The matching function 72 may receive gig demand information(e.g., requests for gig-economy services by customers) and gig supplyinformation (e.g., indications of availability for gig-economy work bygig-economy workers) in order to match gig-economy workers withcustomers for particular gigs. The matching function 72 may also accessadditional data, such as location data, to assign or suggest matches.Additionally, the matching function 72 may manage gigs to avoidduplication of gig-economy work. The verification function 73 maycommunicate with customers or gig-economy workers to verify performanceof gigs, as well as soliciting and receiving rating data relating tocompleted gigs. The payment function 74 may handle electronic paymentfor completed gigs and, in some embodiments, may handle deposits orpartial payments for gigs.

Although the on-demand services network platform 70 is illustrated as asingle block in FIG. 1B, it should be understood that the on-demandservices network platform 70 may be implemented using one or moreservers 40 operating together the implement the gig-economy platform.

Exemplary Mobile Device

FIG. 2 illustrates a block diagram of an exemplary mobile computingdevice 110, consistent with the exemplary gig-economy system 100. Theexemplary mobile computing device 110 may be one of any of the computingdevices associated with a user, vehicle, or other entity discussed above(e.g., an on-board computer 11, a user mobile device 12, a wearablecomputing device 13, an additional mobile device 15, a customercomputing device 20, a connected home device 22 (or smart home device orsensor), or an additional participant computing device 50). In someembodiments, the mobile computing device 110 may also be a part of acontrol or communication system of an autonomous device 30, either as anintegrated subsystem or as a separate system in communicative connectionwith one or more other systems of the autonomous device 30. The mobilecomputing device 110 may include a display 202, a speaker 204, acommunication unit 206, an input 208, internal sensors 108, and acontroller 210. The mobile computing device 110 may be communicativelyconnected to the server 40 via the network 3.

In some embodiments, the mobile computing device 110 and the server 40may be integrated into a single device, or either may perform thefunctions of both. In further embodiments, the mobile computing device110 may be communicatively connected to one or more external sensors120, which may provide additional or alternative data to the dataobtained from the internal sensors 108. Collectively, any set of one ormore of the internal sensors 108 and/or external sensors 120 may bereferred to herein as the “sensors.”

Similar to the controller 55, the controller 210 may include a programmemory 212, one or more processors or microprocessors (MP) 214, a RAM216, and an I/O circuit 218, all of which are interconnected via anaddress/data bus. The program memory 212 may include an operating system220, a data storage 222, a plurality of software applications 230,and/or a plurality of software routines 240. The operating system 220,for example, may include one of a plurality of general purpose or mobileplatforms, such as the Android™, iOS®, or Windows® systems, developed byGoogle Inc., Apple Inc., and Microsoft Corporation, respectively.Alternatively, the operating system 220 may be a custom operating systemdesigned for operation of special-purpose hardware, such as a wearablecomputing device 13 or an on-board computer 11A of a vehicle 10.

The data storage 222 may include data such as user profiles andpreferences, application data for the plurality of applications 230,routine data for the plurality of routines 240, and other data relatedto the autonomous operation features. In some embodiments, thecontroller 210 may also include, or otherwise be communicativelyconnected to, other data storage mechanisms (e.g., one or more hard diskdrives, optical storage drives, solid state storage devices, etc.),which may provide local or remote data storage (e.g., cloud storage).

As discussed with reference to the controller 55, it should beappreciated that although FIG. 2 depicts only one microprocessor 214,the controller 210 may include multiple microprocessors 214. Similarly,the memory of the controller 210 may include multiple RAMs 216 andmultiple program memories 212. Although FIG. 2 depicts the I/O circuit218 as a single block, the I/O circuit 218 may include a number ofdifferent types of I/O circuits. The controller 210 may implement theRAMs 216 and the program memories 212 as semiconductor memories,magnetically readable memories, or optically readable memories, forexample.

The one or more microprocessors 214 may be adapted and configured toexecute any of one or more of the plurality of software applications 230or any one or more of the plurality of software routines 240 residing inthe program memory 212, in addition to other software applications. Thesoftware applications 230 may include various gig-economy platformapplications, mapping applications, insurance applications, or gig workmanagement and tracking applications. Thus, the software applicationsmay include a TNC platform application 232 for finding and performingon-demand transportation gigs, a gig delivery platform application 234for finding and performing product delivery gigs, and a gig workmanagement application 236 for tracking and optimizing gig work.

Such gig work management application 236 may be configured to generateor present gig optimization recommendations or other gig optimizationdata to a user of the mobile computing device 110 (e.g., a gig-economyworker 17). In some embodiments, the gig work management application 236may be configured to present information regarding insurance risks orpolicies relating to performance of gigs, which may include facilitatingor automatically causing the purchase or use of insurance policiescovering gig-economy work.

The plurality of software applications 230 may call various of theplurality of software routines 240 to perform functions relating togig-economy work. The plurality of software routines 240 may thusinclude a clock routine 242 to maintain or determine a current time, asensor control routine 244 to transmit instructions to internal sensors108 or external sensors 120 and to receive data from such sensors, alocation routine 246 that determines a current location using data fromthe GPS unit 250, or a monitoring and reporting routine 248 thattransmits information regarding gig-economy work to the server 40 viathe network 3. Any of the plurality of software applications 230 may bedesigned to operate independently of the software applications 230 or inconjunction with the software applications 230.

The display 202 and speaker 204 of the mobile computing device 110,along with other integrated or communicatively connected output devices(not shown), may be used to present information to the user of themobile computing device 110 or others. The display 202 may include anyknown or hereafter developed visual or tactile display technology,including LCD, OLED, AMOLED, projection displays, refreshable brailledisplays, haptic displays, or other types of displays. The one or morespeakers 204 may similarly include any controllable audible outputdevice or component, which may include a haptic component or device. Insome embodiments, communicatively connected speakers 204 may be used(e.g., headphones, Bluetooth headsets, docking stations with additionalspeakers, etc.). The input 208 may further receive information from theuser. Such input 208 may include a physical or virtual keyboard, amicrophone, virtual or physical buttons or dials, or other means ofreceiving information. In some embodiments, the display 202 may includea touch screen or otherwise be configured to receive input from a user,in which case the display 202 and the input 208 may be combined.

The mobile computing device 110 may further include internal sensors108. The internal sensors 108 may include any devices or componentsmentioned herein, other extant devices suitable for capturing dataregarding a physical environment, or later-developed devices that may beconfigured to provide data regarding a physical environment (includingcomponents of vehicles, structures, or other objects within the physicalenvironment). The internal sensors 108 of the mobile computing device110 may be supplemented by additional sensors 120, in some embodiments,which may be physically and/or communicatively connected to the mobilecomputing device 110 to provide additional data to the mobile computingdevice 110. Some additional sensors 120 may be configured or intendedfor other uses, such as geolocation, movement tracking, photography, orspatial orientation of the device. Such additional sensors 120 may,nonetheless, be used to provide sensor data for gig-economy-relateduses, as discussed herein. As an example, the additional sensors 120 mayinclude one or more additional accelerometers for detecting usermovement during a user trip (i.e., accelerometers installed within avehicle in which the user is traveling or a smart watch worn by theuser).

Although discussion of all possible sensors of the mobile computingdevice 110 would be impractical, if not impossible, several sensorswarrant particular discussion. Disposed within the mobile computingdevice 110, the internal sensors 108 may include a GPS unit 250, anaccelerometer 252, a gyroscope 254, a barometer 256, a camera 258, or amicrophone 260. Any or all of these sensors may be used to generatesensor data associated with user location or gig-economy work.Additionally, other types of currently available or later-developedsensors may be included in some embodiments.

The GPS unit 250 and the accelerometer 252 may provide informationregarding the location or movement of the mobile computing device 110.The GPS unit 250 may use “Assisted GPS” (A-GPS), satellite GPS, or anyother suitable global positioning protocol (e.g., the GLONASS systemoperated by the Russian government) or system that locates the positionof the mobile computing device 110. For example, A-GPS utilizesterrestrial cell phone towers or Wi-Fi hotspots (e.g., wireless routerpoints) to more accurately and more quickly determine location of themobile computing device 110, while satellite GPS generally is moreuseful in more remote regions that lack cell towers or Wi-Fi hotspots.

The accelerometer 252 may include one or more accelerometers positionedto determine the force and direction of movements of the mobilecomputing device 110. In some embodiments, the accelerometer 252 mayinclude a separate X-axis accelerometer, Y-axis accelerometer, andZ-axis accelerometer to measure the force and direction of movement ineach dimension respectively. It will be appreciated by those of ordinaryskill in the art that a three dimensional vector describing a movementof the mobile computing device 110 through three dimensional space canbe established by combining the outputs of the X-axis, Y-axis, andZ-axis accelerometers using known methods.

Similarly, other components may provide additional positioning ormovement sensor data. In some embodiments, a gyroscope 254 may be usedin addition to, or instead of, the accelerometer 252 to determinemovement of the mobile computing device 110. For example, a MEMSgyroscope may be included within the mobile computing device 110 todetect movement of the mobile computing device 110 in three dimensionalspace. Of course, it should be understood that other types of gyroscopesor other types of movement-detecting sensors may be used in variousembodiments. Such sensor data may be used to determine relative movementof the mobile computing device 110 within a physical environment, suchas during a trip. Such relative position information may be combinedwith other sensor data (such as GPS data) to determine movement of themobile computing device 110 along a route. Such additional positioningor movement data may be used to differentiate user movement (e.g.,within a vehicle) from movement of the mobile computing device 110 bythe user (e.g., such as holding a phone to the user's ear during a phonecall).

The camera 258 may be used to capture still or video images of the localphysical environment of the mobile computing device 110. Such images maybe used to identify user location based upon surroundings or todistinguish between movement of the user and movement of the mobilecomputing device 110 by the user. The one or more cameras 258 mayinclude digital cameras or other similar devices, such as charge-coupleddevices, to detect electromagnetic radiation in the visible wavelengthrange or other wavelengths.

It will be readily understood that one or more cameras 258 may bedisposed within the mobile computing device 110 and configured togenerate either still images or video recordings. For example, multiplecameras 258 may be disposed to obtain stereoscopic images of thephysical environment. In some embodiments, the camera 258 may include aninfrared illuminator or other device to stimulate emission within atargeted range. Such infrared illuminators may be automaticallyactivated when light is insufficient for image capturing. Additional oralternative internal sensors 108 may be included in some embodiments tocapture data regarding locations and shapes of objects within thephysical environment.

The microphone 260 may similarly be used to detect sounds within thelocal physical environment, such as spoken notes or comments by the userof the mobile computing device 110. One or more microphones 260 may bedisposed within the mobile computing device 110 or may becommunicatively connected thereto. For example, wired or wirelessmicrophones 260 may be communicatively connected to the mobile computingdevice 110, such as wireless speaker/microphone combination devicescommunicatively paired with the mobile computing device 110.

The mobile computing device 110 may also communicate with the server 40or other components via the network 3. Such communication may involvethe communication unit 206, which may manage communication between thecontroller 210 and external devices (e.g., network components of thenetwork 3). The communication unit 206 may further transmit and receivewired or wireless communications with external devices, using anysuitable wireless communication protocol network, such as a wirelesstelephony network (e.g., GSM, CDMA, LTE, etc.), a Wi-Fi network (802.11standards), a WiMAX network, a Bluetooth network, etc. Additionally, oralternatively, the communication unit 206 may also be capable ofcommunicating using a near field communication standard (e.g., ISO/IEC18092, standards provided by the NFC Forum, etc.). For example, suchnear field communication may be used to activate or access atransportation mode (e.g., by using an electronic ticket or unlocking avehicle door of a vehicle-sharing vehicle). Furthermore, thecommunication unit 206 may provide input signals to the controller 210via the I/O circuit 218. The communication unit 206 may also transmitsensor data, device status information, control signals, or other outputfrom the controller 210 to the server 40 or other devices via thenetwork 3.

Exemplary Gig-Economy Work Flow Methods

FIG. 3 illustrates a flow diagram of an exemplary gig-performance method300 to indicate a typical work flow of gig creation, matching,performance, and payment in the gig-economy. The gig-performance method300 is exemplary only, and other methods may include additional, fewer,or alternative actions. Various parts of the gig-performance method 300may be implemented by or performed using the various front-endcomponents 2 and back-end components 4, which may communicate via thenetwork 3, as described above. In some embodiments, the gig-performancemethod 300 may be implemented by one or more servers of an on-demandservices network platform 70 (e.g., one or more servers 40 configured toimplement a single gig-economy platform).

At block 302, the gig-performance method 300 may begin by receivingavailability data for a plurality of gig-economy workers at a server 40from mobile computing devices 110 associated with gig-economy workers 16and 17. The availability data may include current locations of each ofthe gig-economy workers. In some embodiments, additional current detailsrelated to some or all of the gig-economy workers may also be received.

At block 304, the server 40 may further receive a gig request from acustomer mobile device 20. The gig request may specify gig details, suchas locations, times, or types of gig-economy work to be performed. Forexample, a gig request may indicate a current or future request foron-demand transportation service from a first location to a secondlocation.

At block 306, the server 40 may match one of the plurality ofgig-economy workers with the customer request to assign the gig. Thismatching may include determining a subset of gig-economy workersmatching the details of the gig request, such as location, skills,gig-worker rating, customer rating, type of vehicle, time availability,travel availability, etc. The subset of gig-economy workers may beranked based upon a quality of matches. The server 40 may then attemptto match the gig request with one or more of the gig-economy workers inthe subset of gig-economy workers by sending a proposed match to one ormore gig-economy workers, the customer, or both.

At block 308, the server 40 may confirm the match with one of thegig-economy workers, the customer, or both. Confirming the match mayrequire active selection of the gig by one or both parties, or the matchmay be confirmed by inaction after a predetermined period of timefollowing a notification of the proposed match. Confirmation of thematch may create the gig on the gig-economy platform.

At block 310, the server 40 may provide gig-related information to oneor both of the gig-economy worker or the customer prior to or duringperformance of the gig. Such gig-related information may include timinginstructions or predictions, recommended travel routes, or deliveryinstructions. In some embodiments, the server 40 may provide sequentialgig-related information at a plurality of stages of the gig, such asdirections to a pick-up location followed by directions to a drop-offlocation.

At block 312, the server 40 may receive an indication of gig completionfrom one or both of the gig-economy worker or the customer when the gigis finished. Such indication of gig completion may include ratinginformation or comments on the gig.

At block 314, the server 40 may process payment for the gig from thecustomer. The server 40 may further process payment to the gig-economyworker, either immediately or in an aggregated transfer at a later time.Payments may be processed by electronic fund transfers or charges usingpreviously linked financial accounts.

Exemplary Computer-Implemented Method for Monitoring and EvaluatingCommercial Driving Activity

Generally speaking, to insure a gig-economy worker, an insuranceprovider may consider and analyze a number of factors. For example, theinsurance provider may use telematics and/or other data to monitor oridentify driving behaviors of a gig-economy worker (e.g., gig-economyworker 17) during a gig. The data may be used to score gig-economyworkers based upon their driving behaviors and/or develop commercialdriving profiles/ratings/scores. Further, the telematics and/or otherdata may be used to monitor differences in gig-economy workercommercial/personal driving behaviors.

Because gig-relating commercial driving behavior may differsignificantly from personal driving behavior of the gig-economy worker,distinguishing between gig-related driving and non-gig-related drivingmay result in a significant reduction in the cost of personal drivinginsurance for the gig-economy worker. Moreover, limited insurancepolicies for gig-related driving may be offered to the gig-economyworker, along with information or recommendations to reduce riskassociated with gig-economy work. Such information may include estimatedor actual costs associated with such risk (e.g., insurance policypremiums or expected values of losses associated with gig-economy work).

A. Exemplary Driving Monitoring Method

FIG. 4 illustrates a flow diagram of an exemplary gig-economy drivingmonitoring method 400 for monitoring and evaluating commercial drivingactivity. The method 400 begins by receiving availability datacorresponding to a gig worker (block 402). In certain embodiments, theavailability data may indicate a beginning of a commercial interactionbetween the gig-economy worker (e.g., gig-economy worker 17) and acustomer (e.g., a gig-economy customer 21). However, it should beunderstood that the availability data may indicate a gig-economy workeractivating a gig-economy platform application on a mobile device and/orany other suitable action or combination thereof. For example, thegig-economy worker 17 may activate a gig-economy platform application ona user mobile computing device 110 (e.g., on-board computer 11A or usermobile device 12) to initiate participation in the gig-economy system100. By activating the mobile application, the mobile computing devicemay transmit the availability data to an external server (e.g., fleetmanagement server 45) to facilitate the gig-economy worker matching witha customer, as described herein. Block 402 may be performed by, forexample, a fleet management server 45.

The method 400 continues by collecting a set of data indicative of oneor more driving behaviors of the gig-economy worker (block 404).Generally, the set of data may include telematics and/or other data,such as environmental data. The telematics data may include informationregarding vehicle operation, such as driving speed, braking,acceleration, distance from other vehicles, turns, lane changes, route,origination, destination, direction of travel, fuel usage, and/or otheraspects of vehicle operation. In certain embodiments, the environmentaldata may include one or more of (i) a road condition, (ii) a weathercondition, (iii) a nearby traffic condition, (iv) a road type, (v) aconstruction condition, (vi) a presence of pedestrians, or (vii) apresence of other obstacles.

The set of data may be collected at or via a mobile device, or in someembodiments, a server. Moreover, the set of data may be generated bysensors affixed to or associated with the vehicle driven by thegig-economy worker, sensors incorporated in a mobile device, or in someembodiments, associated with a plurality of vehicles and/or aninfrastructure component (e.g., a traffic camera, a speed radar device,etc.). Each of these sensors may be internal sensors 108 or externalsensors 120 of a corresponding mobile computing device 110, as describedabove. For example, the telematics and/or other data may be generated byor include information related to vehicle-to-vehicle (V2V)communications and/or vehicle-to-infrastructure (V2I) communications.Block 404 may be performed by, for example, the on-board computer 11A oruser mobile device associated with the gig-economy worker 17.

The telematics data and/or other data may indicate one or more drivingbehaviors of a gig-economy worker. The telematics data may indicate thespeed at which the gig-economy worker typically drives; the type ofvehicle that the gig-economy worker typically drives; the type of roadsor routes that the gig-economy worker usually takes; the distance atwhich the gig-economy worker typically trails other vehicles; whetherthe gig-economy worker drives a large percentage of time adjacent toother vehicles traveling in the same direction (such as on a four-lanehighway); whether the gig-economy worker typically drives too slow ortoo fast in relation to the posted speed limit, or in relation to othervehicles on the road; and/or other driving behaviors of the gig-economyworker. Similarly, the other data may indicate the weather conditions inwhich the gig-economy worker will normally drive; the locations wherethe gig-economy worker typically drives; and/or the dates/times of dayduring which the gig-economy worker usually drives or drives the most.

As an example, the telematics data may include information related tothe operation of one or more vehicles identified by one or moreprocessors (e.g., processor 214 of mobile computing device 110) basedupon analysis of the telematics and/or other data. Analysis of the datamay reveal the amount and/or type of other vehicles a gig-economy workeruses. Data collected (such as by the mobile computing device 110) mayreveal that the gig-economy worker uses a safer vehicle (e.g., a vehiclewith a higher safety rating) a certain percentage of the time. The datamay further be used to determine times and/or places in which thegig-economy worker uses the safer vehicle. The gig-economy worker mayuse the safer vehicle when performing a gig and a less safe vehicle whendriving for personal use. If the gig-economy worker commonly transportscustomers (e.g., gig-economy customers 21) using a safer vehicle, thatmay indicate that the gig-economy worker is typically risk-averse in agig setting.

People who are risk-averse may in turn typically have less risk ofaccident or injury, so determining such risk aversion of the gig-economyworker may be used to offer gig insurance policies to the gig-economyworker at a lower cost. Consequently, the substantial overlap oftimestamps indicating safe vehicle usage with the availability data mayindicate that the gig-economy worker consistently/frequently transportsgig-economy customers in a high safety-rating vehicle.

As an example, the set of data may reveal location information, such aswhere the gig-economy worker drives. The risk for open road or highwaydriving may be less than the risk associated with downtown or citydriving. Highway driving may indicate that a gig-economy worker is notdriving through a large amount of intersections, and/or typicallydriving greater distances from other vehicles on the road (i.e., lessbumper-to-bumper driving). Driving over a certain speed, such as 45 mph,may also indicate that a gig-economy worker normally drives on thehighway, and thus may have a lower risk of accident. Consequently, ifthe set of data includes location data associated with a highway andspeed data consistent with the speed limit of the highway, the set ofdata may indicate that a gig-economy worker consistently/frequentlytransports gig-economy customers on highways.

As another example, the set of data may include time and/or time of dayinformation. The data may include a percentage of time that the vehiclespends on highways (which may be associated with a relatively low risk),and/or a percentage of time that the vehicle spends in parking lots(which may be associated with a relatively high risk). The set of datamay also indicate normal traffic conditions associated with agig-economy worker, and/or the percentage of time that a vehicle used bya gig-economy worker is not being driven and/or parked in a public place(such as on the street), but rather is stored or housed inside and/or ina secure location (such as in the garage of the owner). Storing avehicle inside may prevent theft and/or damage from the environment,such as wind or hail damage. Consequently, if the set of data includestime data indicating a large amount of highway driving time and lowtraffic data consistent with the normal traffic flow of the highway, theset of data may indicate that a gig-economy workerconsistently/frequently transports gig-economy customers on highways.

As yet another example, the set of data may include the number of milesthat a gig-economy worker typically drives during a gig. More milesdriven may indicate more risk, which may further depend upon type ofroad traveled. The set of data may also indicate the type, make, ormodel of a vehicle that is driven by the gig-economy worker. Certainvehicle types, makes, or models may have superior safety, equipment, orother vehicle ratings. Consequently, if the set of data includes atypical number of miles driven by the gig-economy worker during a gigindicating a short typical gig distance and a vehicle with a high safetyrating, the set of data may indicate that the gig-economy workerconsistently/frequently transports gig-economy customers over shortdistances in a safe vehicle (e.g., a low risk gig).

In some embodiments, the set of data may facilitate mood detection inreal-time or building an average mood profile for the gig-economyworker. The mood of a gig-economy worker may impact driving behavior.Soft or light music may indicate that the gig-economy worker is relaxedand calm while driving. Conversely, loud music may indicate that thegig-economy worker is in an aggressive mood. A mobile device or smartvehicle application may detect the songs or type of music usually playedon the vehicle sound system or radio, and/or loudness thereof.

In some embodiments, the gig-economy worker may be an autonomous vehiclesystem. For example, a gig-economy worker may be present in the vehicle,and enable one or more autonomous features of the autonomous vehiclesystem, such that the one or more autonomous features make decisions tocontrol or otherwise impact the control of the vehicle during a gig. Inthese embodiments, the set of data may include the decisions implementedby autonomous vehicle system to control or otherwise impact the controlof the vehicle during gig performance. For example, in response toenabling the one or more autonomous features, a processor may create atimestamp. The timestamp may include information regarding the date,time, location, vehicle environment, vehicle condition, and autonomousoperation feature settings or configuration information. The date andtime may be used to identify a gig or one period of autonomous operationfeature use, in addition to indicating risk levels due to traffic orother factors.

The location and environmental data included in the set of data mayinclude information regarding the position of the vehicle (e.g., via theGPS unit 250) and its surrounding environment (e.g., road conditions,weather conditions, nearby traffic conditions, type of road,construction conditions, presence of pedestrians, presence of otherobstacles, availability of autonomous communications from externalsources, etc.). Vehicle condition information may include informationregarding the type, make, and model of the vehicle, the age or mileageof the vehicle, the status of vehicle equipment (e.g., tire pressure,non-functioning lights, fluid levels, etc.), or other informationrelating to the vehicle. In some embodiments, the timestamp may berecorded on the mobile computing device 110, or an external server(e.g., server 40).

More generally, when the gig-economy worker is an autonomous vehiclesystem, the processor executing instructions in accordance with theexemplary method 400 may be communicatively connected with or otherwiseclosely monitor the sensors comprising the autonomous vehicle system.For example, the processor may execute instructions to determineconfiguration information associated with the autonomous vehicle system.

The configuration information may correspond to information regardingthe number and type of the sensors included in the autonomous vehiclesystem (e.g., included in the on-board computer 11), the disposition ofthe sensors within the vehicle, the one or more autonomous operationfeatures, autonomous operation feature control software, versions of thesoftware applications or routines implementing the autonomous operationfeatures, or other related information regarding the autonomousoperation features. For example, the configuration information mayinclude the make and model of the vehicle (indicating installed sensorsand the type of on-board computer 11), an indication of a malfunctioningor obscured sensor in part of the vehicle, information regardingadditional after-market sensors installed within the vehicle, a softwareprogram type and version for a control program installed as anapplication on the on-board computer 11, and software program types andversions for each of a plurality of autonomous operation featuresinstalled as applications or routines in the program memory of theon-board computer 11.

Once activated to perform during a gig, the sensors of the autonomousvehicle system may generate sensor data regarding the vehicle and itsenvironment. In some embodiments, one or more of the sensors maypreprocess the measurements and communicate the resulting processed datato the on-board computer 11. The sensor data may include informationregarding the vehicle's position, speed, acceleration, direction, andresponsiveness to controls. The sensor data may further includeinformation regarding the location and movement of obstacles orobstructions (e.g., other vehicles, buildings, barriers, pedestrians,animals, trees, or gates), weather conditions (e.g., precipitation,wind, visibility, or temperature), road conditions (e.g., lane markings,potholes, road material, traction, or slope), signs or signals (e.g.,traffic signals, construction signs, building signs or numbers, orcontrol gates), or other information relating to the vehicle'senvironment. In some embodiments, the autonomous vehicle system sensorsmay indicate the number of gig-economy customers within the vehicle,including an indication of whether the vehicle is entirely empty.

In addition to receiving sensor data from the sensors, in someembodiments the processor may receive autonomous communication data froma communication component or a communication module of the autonomousvehicle system. The communication data may include information fromother autonomous vehicles (e.g., sudden changes to vehicle speed ordirection, intended vehicle paths, hard braking, vehicle failures,collisions, or maneuvering or stopping capabilities), infrastructure(road or lane boundaries, bridges, traffic signals, control gates, oremergency stopping areas), or other external sources (e.g., mapdatabases, weather databases, or traffic and accident databases).

The communication data may be combined with the sensor data and includedin the set of data to obtain a more robust understanding of the vehicleenvironment. For example, the processor may combine sensor dataindicating frequent changes in speed relative to tachometric data withmap data relating to a road upon which the vehicle is traveling todetermine that the vehicle is in an area of hilly terrain. As anotherexample, weather data indicating recent snowfall in the vicinity of thevehicle may be combined with sensor data indicating frequent slipping orlow traction to determine that the vehicle is traveling on asnow-covered or icy road.

In any event, the exemplary method 400 continues by determining a riskscore for each driving behavior (block 406). Generally, the one or moreprocessors may determine the risk scores by applying a risk model toeach of the indicated driving behaviors, either separately or togetherwith other driving behaviors. The risk model may include pre-determinedrisk values for each driving behavior, the model may compare eachdriving behavior to a set of known driving behaviors of othergig-economy workers, and/or the model may utilize machine learning toadaptively determine risk scores for each driving behavior. The riskmodel may be stored in and retrieved from local memory (e.g., programmemory 212), external memory/servers (e.g., account server 41, server40), and/or otherwise accessed for use. Block 406 may be performed by,for example, the processor 214 of mobile computing device 110 orprocessor 62 of server 40.

In certain embodiments, the risk model includes a set of known drivingbehaviors of other gig-economy workers. The set of known drivingbehaviors may include information regarding typical or average drivingbehaviors for a specific driving environment and/or type of drivingenvironment. The set of known driving behaviors may be generated,developed, and/or determined based upon telematics and/or other dataregarding driving behavior of a plurality or group of gig-economyworkers and/or vehicles. For example, the set of known driving behaviorsmay be determined from telematics data collected from hundreds orthousands of gig-economy workers and/or individual gigs in an areaand/or along a particular portion of a roadway (e.g., a city, a censustract, a parking lot, a block of a street, a highway section, anintersection, an entrance or exit ramp, etc.). The set of known drivingbehaviors may be compared with the insured's driving behavior to analyzeand/or determine a risk score for the insured.

For example, the set of data may indicate an average speed that thegig-economy worker normally drives at as compared to typical gig-economyworkers, and/or average gig-economy workers in a given community orgeographical area. Speed data may be gathered that indicates the averagespeed of other gig-economy workers in a given area or on a given stretchof road. The speed data may also indicate average braking events (e.g.,number of braking events, whether such braking is hard or soft,deceleration rate during braking, distance to stop, etc.) or aggressivedriving (or lack thereof) for other gig-economy workers on a givenstretch of road.

When the gig-economy worker is on the same road as the road for whichother gig-economy worker data is collected, data related to thegig-economy worker's specific vehicle speed and braking may becollected. If the gig-economy worker's vehicle speed on that road isbelow the speed indicated for the other gig-economy workers, it mayindicate that the gig-economy worker typically drives below the speedlimit and/or in a low risk manner. Conversely, if the gig-economyworker's vehicle speed on that road (or stretch of road or location) isabove an average or many of the other gig-economy worker speeds, thatmay indicate the gig-economy worker typically drives in a more riskymanner.

If the gig-economy worker's vehicle braking information indicates thatthe gig-economy worker brakes a below-average amount, that may beindicative that the gig-economy worker trails other vehicles at arisk-averse distance, does not tailgate, and/or otherwise drives in alower-risk manner. Conversely, if the vehicle braking informationindicates that the gig-economy worker brakes an excessive orabove-average amount, that may indicate that the gig-economy worker istypically following other vehicles too closely and/or potentiallydriving in a manner associated with above-average risk.

In some embodiments, GPS data from a number of other gig-economy workersmay be gathered. A database of other gig-economy workers' behavior oncertain roads or areas may be built, such as demonstrating the speedand/or braking of the average gig-economy worker on a specific sectionof road. Telematics and/or other data, including GPS data (e.g., via GPSunit 250), associated with the gig-economy worker may be collected andcompared with the other gig-economy worker characteristics for specificsections of road. If lower than average risk is identified by thebehavior exhibited by the gig-economy worker, the one or more processorsmay then determine a low risk score for the gig-economy workerassociated with a specific section of road.

As previously mentioned, the risk model may utilize machine learning toadaptively determine risk scores for each driving behavior. Generally,machine learning may involve identifying and recognizing patterns inexisting data (such as autonomous vehicle system, feature, or sensordata; autonomous vehicle system control signal data; vehicle-mountedsensor data; mobile device sensor data; and/or telematics, image, orradar data) in order to facilitate making predictions for subsequentdata. Machine learning models may be created based upon example inputsof data in order to make valid and reliable predictions for novelinputs.

In supervised machine learning, a processing element may be providedwith example inputs and their associated outputs, and may seek todiscover a general rule that maps inputs to outputs, so that whensubsequent novel inputs are provided the processing element may, basedupon the discovered rule, accurately predict a correct or preferredoutput. In unsupervised machine learning, the processing element may berequired to find its own structure in unlabeled example inputs. Incertain embodiments, machine learning techniques may be used to extractthe one or more driving behaviors from the set of data, and determinerisk scores for each driving behavior.

For example, the one or more processors may train a machine learningmodel based upon (i) a set of prior driving behaviors, and (ii) a set ofprior risk scores. Further, the one or more processors may apply themachine learning model to the set of data to generate the risk score foreach indicated driving behavior. The machine learning programs mayutilize deep learning algorithms that are primarily focused on patternrecognition, and may be trained after processing multiple examples. Themachine learning programs may include Bayesian program learning (BPL),voice recognition and synthesis, image or object recognition, opticalcharacter recognition, and/or natural language processing—eitherindividually or in combination. The machine learning programs may alsoinclude natural language processing, semantic analysis, automaticreasoning, and/or machine learning.

The machine learning programs may be trained with the set of priordriving behaviors and the set of prior risk scores to identifyrelationships between and among driving behaviors and theircorresponding risk scores. Accordingly, upon receipt of the set of data,the machine learning programs may determine a risk score for eachdriving behavior indicated in the set of data.

Moreover, in certain embodiments where the gig-economy worker activatesone or more features of an autonomous vehicle system, the one or moreprocessors may execute instructions to determine a risk score for theautonomous vehicle system based upon the one or more control decisionsmade by the autonomous vehicle system. The information regarding thecontrol decisions generated by the autonomous vehicle system may includeinformation regarding control decisions not implemented to control thevehicle. The control decisions not implemented to control the vehiclemay include an alternative control decision not selected by theautonomous vehicle system to control the vehicle. Additionally oralternatively, the control decisions not implemented to control thevehicle may include a control decision not implemented because the oneor more features were disabled.

In these embodiments, the control decisions may be generated by theautonomous vehicle system to direct the vehicle to turn left, turnright, exit onto an off ramp, enter onto a highway, slow down,accelerate, stop, merge left or merge right, signal a lane change orturn, change lanes, stop at an intersection or stop light, and/or parkthe vehicle. The control decisions may also be related to controldecisions (directing the autonomous system or vehicle operation)associated with, for example, whether to apply the brakes; how quicklyto apply the brakes; an amount of force or pressure to apply to thebrakes; how much to increase or decrease speed; how quickly to increaseor decrease speed; how quickly to accelerate or decelerate; how quicklyto change lanes or exit; the speed to take while traversing an exit oron ramp; at what speed to approach a stop sign or stop light; howquickly to come to a complete stop; and/or how quickly to acceleratefrom a complete stop.

The set of data may also include reasons as to why one or more controldecisions were executed or not executed by the autonomous vehiclesystem. For example, the control decisions may be entered into a log ofoperating data that includes such reasons. The reason as to why one ormore controls decisions were not executed by the autonomous vehiclesystem may be that the autonomous system software was corrupted or anautonomous vehicle system sensor was malfunctioning or not workingproperly. The reason as to why one or more controls decisions were notexecuted by the autonomous vehicle system may be that the autonomousvehicle system determined that (i) the autonomous vehicle systemsoftware was corrupted, or (ii) an autonomous vehicle system sensor wasmalfunctioning or not working properly. The reason as to why one or morecontrols directed were not executed by the autonomous vehicle system maybe that the autonomous vehicle system was overridden by the gig-economyworker, or already engaged by the gig-economy worker. Additional oralternate reasons may also be determined.

The set of data may also include external data from the log of operatingdata. As previously discussed, the external data may includeidentification of information regarding road conditions, weatherconditions, nearby traffic conditions, type of road, constructionconditions, presence of pedestrians, and presence of other obstacles. Itis to be appreciated that the set of data may additionally include anysuitable data captured, generated, or otherwise acquired by theautonomous vehicle system.

The method 400 continues by determining a commercial driving profilecorresponding to the gig-economy worker (block 408). Generally, thecommercial driving profile may indicate a quality assessment of thegig-economy worker based upon the risk scores calculated for eachdriving behavior indicated for the gig-economy worker during a gig. Thecommercial driving profile may include each risk score for each drivingbehavior; when and where the gig-economy worker is driving an insured orother vehicle during gigs; what type of vehicle the gig-economy workertypically drives during gigs; and/or other conditions or factors relatedto operation of the vehicle during one or more gigs, including thosediscussed elsewhere herein.

Thus, the commercial driving profile includes information specificallyrepresentative of a gig-economy worker's performance and drivingbehavior during a gig. Additionally or alternatively, the commercialdriving profile may represent a gig-economy worker's performance ordriving behavior during periods indicated in the timestamps of theavailability data. Accordingly, the commercial driving profile maydiffer from a profile representative of the gig-economy worker's drivingbehavior during personal use of the vehicle. Block 408 may be performedby, for example, the processor 62 of server 40.

The exemplary method 400 may continue by determining an adjustment to aninsurance policy associated with the gig-economy worker (optional block410). In certain embodiments, the adjustment to the insurance policy maybe an offer to accept or reject an insurance policy. The insurancepolicy may be a gig insurance policy specifically tailored to coveraccidents or other incidents that may occur during a gig or duringgig-economy work over a period of time. For example, based upon thecommercial driving profile, the gig-economy worker may receive an offerto accept or reject a gig policy that covers accidents and/or otherincidents that may occur while the gig-economy driver is performing agig. Additionally or alternatively, the gig-economy worker may receivebenefits, incentives, and/or other discounts to a premium, deductible,rate, and/or any other suitable value associated with an alreadyexisting gig policy.

Of course, as gig-economy workers continue to perform gigs, theirbehaviors may change over time. In order to make higher profits orsimply spend less time per gig, a gig-economy worker may drive moretenaciously. If a gig-economy worker prefers to decrease the number ofgigs performed while maintaining a profit level, the gig-economy workermay accept gigs featuring longer routes. Thus, one or more processorsmay occasionally collect data corresponding to a gig-economy worker'sperformance during gigs to update their corresponding commercial drivingprofile.

B. Exemplary Gig-Economy Driving Data Collection Method

FIG. 5 illustrates a flow diagram of an exemplary gig-economy drivingdata collection method 500 for determining whether a set of dataindicative of one or more driving behaviors of the gig-economy workerhas been collected within a determined interval period and, if not,collecting data. A processor (e.g., processor 62 of server 40 orprocessor 214 of mobile computing device 110) may execute an instructionto determine an interval period for collecting, requesting, ortransmitting data (block 502).

Generally, a company that maintains the commercial driving profile maydetermine an interval period for transmitting data. For example, if aninsurance company that insures the gig-economy worker maintains thecommercial driving profile, the insurance company may pre-determine theinterval period to be hours, days, months, years, etc. In certainembodiments, a gig-economy worker may set a preference for an intervalperiod. The processor may execute an instruction to determine whether ornot a set of data has been collected within the interval period (block504). If the processor executing the instruction determines that a setof data has been collected within the interval period (YES branch ofblock 504), then the processor may execute an instruction to end theexemplary method 500 (block 506).

If the processor executing the instruction determines that a set of dataindicative of one or more driving behaviors of the gig-economy workerhas not been collected within the interval period, (NO branch of block504) then the processor may execute an instruction to receiveavailability data from a computing device associated with thegig-economy worker (block 508). In this circumstance, the availabilitydata may indicate whether a gig-economy worker is currently performing agig. For example, the processor may query the mobile computing device ofthe gig-economy worker, or other suitable device the gig-economy workeruses to perform gigs, to receive an indication whether any of thegig-economy platform applications are active. In this manner, theprocessor may determine whether the gig-economy worker is currentlyperforming a gig (block 510).

If the processor receives availability data indicating the gig-economyworker is not currently performing a gig (NO branch of block 510), theprocessor may execute an instruction to return the exemplary method 500to block 504. However, if the processor receives availability dataindicating the gig-economy worker is currently performing a gig (YESbranch of block 510), the processor may execute an instruction tocollect a set of data indicative of one or more driving behaviors of thegig-economy worker (block 512). Further, the processor may execute aninstruction to analyze the set of data and determine a risk score foreach driving behavior indicated in the set of data (block 514), asdescribed herein. Accordingly, the processor may execute an instructionto utilize the risk scores by updating a commercial driving profileassociated with the gig-economy worker (block 516).

For example, assume that the processor receives availability dataindicating the gig-economy worker is currently performing a gig (YESbranch of block 510). The processor may receive a set of data thatcorresponds to a time period encompassing the current gig and any gigsthe gig-economy worker performs until the gig-economy worker disconnectsfrom all or some gig-economy platform applications (e.g.,rideshare/on-demand transportation, food delivery, package delivery,etc.). The set of data may indicate that both an average speed and anaverage distance per gig performed by the gig-economy worker during thetime period is higher compared to an average speed and an averagedistance per gig indicated in the commercial driving profile associatedwith the gig-economy worker.

Further in this example, the set of data may indicate a location of thegigs performed in the time period that differs from the typical positionof gigs indicated in the commercial driving profile associated with thegig-economy worker. As previously mentioned, the processor may identifythe location (e.g., using GPS data via GPS unit 250) and apply a riskmodel to determine a risk score for each behavior in light of thelocation. In this example, assume the processor identifies the locationas a low traffic density highway. The processor may then determine thatthe higher average speed and average distance per gig correspond to alower overall risk because these driving behaviors are consistent withhighway driving, and the particular highway has a low traffic density.

It is to be appreciated that the exemplary method 500 may be performedin accordance with a machine learning model, as described herein. Forexample, a processor may utilize a machine learning model to update thecommercial driving profile associated with a gig-economy worker. Theprocessor may train the machine learning model with prior determinedinterval data or a predetermined interval period, one or more prior setsof data, and one or more prior risk scores. The processor may thenexecute instructions in accordance with the machine learning model toautomatically determine an interval period (block 502); determinewhether data has been collected within the interval period (block 504);end the exemplary method 500 if data has been collected within theinterval period (block 506); receive the availability data (block 508);determine whether the gig-economy worker is currently performing a gig(block 510); collect a set of data indicating one or more drivingbehaviors of the gig-economy worker (block 512); determine a risk scorefor each driving behavior indicated in the set of data (block 514);and/or update a commercial driving profile associated with thegig-economy worker (block 516).

Another point of emphasis gig-economy workers commonly express ismaximizing gig performance. Gig-economy workers want to understand howthey are evaluated, and techniques they can implement to improve theirratings, scores, etc. Higher ratings or scores may result in more orbetter gigs being available to or assigned to the gig-economy worker bya gig-economy platform, which in turn can enable the gig-economy workersto generate more revenue and increase profits. Consequently, a method toprovide a gig-economy worker with real-time feedback (referenced hereinas “education points”) regarding their gig performance is highlydesired.

C. Exemplary Gig-Economy Driving Education Point Method

FIG. 6 illustrates a flow diagram of an exemplary gig-economy drivingeducation point method 600 of determining an education point for displayto a gig-economy worker. In certain embodiments, the method 600 may beimplemented in whole or in part by one or more components of the server40 or the mobile computing device 110. For example, the method 600 maybe implemented by a server 40 remote from the front-end components 2(e.g., vehicles 10 or 14, mobile devices 12 or 15, autonomous devices30, etc.) or another server of the back-end components 4. In someembodiments, the front-end components 2 may be used to generate and/orcollect data relating to driving behavior of multiple drivers, includinggig-economy worker 17 associated with the vehicle 10. The method 600 isexemplary and may include additional, fewer, or alternate actions,including those discussed elsewhere herein.

The method 600 may begin by collecting telematics and/or other dataassociated with a gig-economy worker (block 602). The telematics and/orother data may include information regarding vehicle operation, such asdriving speed, braking, acceleration, cornering, distance from othervehicles, turns, lane changes, direction, heading, route, origination,destination, time-of-day, and/or other aspects of vehicle operation.Such data may be collected at or via a server, such as an insuranceprovider remote server. In certain embodiments, the telematics and/orother data may be generated by sensors associated with a plurality ofvehicles and/or an infrastructure component (e.g., a traffic camera, aspeed radar device, etc.). The telematics and/or other data may also begenerated by or include information related to vehicle-to-vehicle (V2V)communications and/or vehicle-to-infrastructure (V2I) communications.

In some embodiments, collecting the telematics and/or other dataassociated with the gig-economy worker may include collecting telematicsand/or other data associated with other drivers. Further the method 600may include determining an average driver profile indicative of drivingbehavior of a plurality of other drivers. The average driver profile maybe generated periodically by a server (e.g., monthly, quarterly,annually, etc.). One or more average driver profiles may be generatedand used for comparison with the gig-economy worker commercial drivingprofile, as discussed herein. By using an average driver profile,significant improvements in efficiency of computing resources (e.g.,processor usage, data communication, memory storage, etc.) usage may beachieved relative to a direct comparison of the gig-economy workercommercial driving profile against information relating to a pluralityof other drivers. In some embodiments, the average driver profile may belimited in scope to a number of classes and/or types of information,which may further improve processing and/or memory storage efficiency.

The method 600 may continue by comparing and/or analyzing the telematicsand/or other data with a risk model to identify low risk driving, highrisk driving, or risk scores associated with the driving behavior, asdescribed herein (block 604). This may include determining and/oridentifying (at a server or at another computing device) high or lowrisk behavior, in accordance with the risk model. In some embodiments,this may include a comparison of telematics data regarding a pluralityof driving behaviors and/or risk-indicating behaviors. For example, therisk model may include comparisons related to speed (block 606A),braking (block 606B), acceleration or deceleration (block 606C), averagedistance to the next vehicle (block 606D), and/or an optional comparisonof environmental conditions (block 606E). Other comparison of drivercharacteristics and/or behavior may also be made using the telematicsand/or other data with the risk model, as previously described.

The method 600 may continue by determining a risk score for thegig-economy worker based upon the comparisons of the gig-economyworker's driving behavior with the value incorporated in the risk model(block 608). A remote server (e.g., server 40) or other suitablecomputing device (e.g., mobile computing device 110) may be used todetermine one or more risk scores based upon the one or more drivingbehaviors identified and/or determined in blocks 604 and/or 606A-E. Theone or more risk scores may indicate an absolute risk level associatedwith the vehicle and/or gig-economy worker, or in some embodiments, theone or more risk scores may indicate relative risk levels in comparisonwith one or more risk scores associated with the other drivers and/ordriver behavior.

In certain embodiments, multiple risk scores may be combined into onerisk score, which may be a weighted combination of the multiple riskscores. Where a weighted combination is determined, the weights may bedetermined manually or automatically by known or later-developedcomputer-learning methods (e.g., support vector machines, randomforests, artificial neural networks, etc.). In some embodiments, therisk score may also include one or more risk aversion scores indicatinga general risk preference profile or level of the gig-economy worker.

The method 600 may continue by adjusting, updating, and/or generating acommercial driving profile associated with the gig-economy worker, basedupon the one or more risk scores for the gig-economy worker determinedat block 608 (block 610). In certain embodiments, a remote server orother suitable computing device may additionally determine a change toan insurance policy based upon the one or more risk scores. For example,a discount may be generated for an insurance policy when a determinedrisk score indicates that the gig-economy worker operates a vehicle in arisk averse manner or in a manner that results in lower risk than theaverage risk associated with other drivers. In some embodiments, agig-economy worker and/or other party may be notified or warnedregarding the risk scores, adjustment, and/or update.

The method 600 may continue by determining an education point for thegig-economy worker based upon the update, adjustment, and/or generationof the commercial driving profile (block 612). Generally speaking, aneducation point may be any message, audio/visual cue, and/or other formof feedback intended to inform a gig-economy worker about a particularbehavior. The particular behavior may be related to any controlfunctions of a vehicle, such as accelerating, braking, cornering,steering, etc., as well as environmental feedback (e.g., interior audiolevels too high, road slippery, internal temperatures too high, etc.).

A computer processor (e.g., processor 62 of server 40 or processor 214of mobile computing device 110) may determine the education point basedupon an education model. For example, the computer processor may storeand access the education model via a memory after receiving thetelematics and/or other data. The education model may have predeterminededucation points for display in response to the telematics and/or otherdata. Additionally or alternatively, the education model may activelydetermine education points for display based upon the telematics and/orother data.

This may include determining and/or identifying (at a server or atanother computing device) high and/or low risk behavior. This may alsoinclude determining associations and/or correlations between the dataand risk preferences and/or levels associated with one or moregig-economy workers. For example, data indicating a gig-economy workermaintains a greater distance from vehicles traveling ahead of thegig-economy worker may be used to determine risk scores or levels foreither or both of a driving behavior and/or general risk preferences ofthe gig-economy worker.

As an example, assume a computer processor receives data indicating thatthe gig-economy driver is following a proximate vehicle at a distance of2 feet. This distance of 2 feet may comprise the distance to nextvehicle data in block 606D. The computer processor may further determinethat any distance to a next vehicle under 5 feet is too close to thenext vehicle. Accordingly, the computer processor may determine aneducation point intended to inform the gig-economy worker to increasetheir following distance. The education point may include a display suchas “Slow Down,” “Too Close,” or any other suitable indication. Toprovide context for such recommendation, in some embodiments theeducation point may include an indication of a cost associated with theeducation point (e.g., a cost differential in a gig insurance policy oran expected value of a risk differential from continuing to follow tooclosely compared with adjusting to a safer following distance).

Moreover, the education point may indicate that the gig-economy workeris following the next vehicle by 2 feet. The education point may includemultiple messages, and may scroll across the surface of a display (e.g.,display 202), or simply alternate between/among different educationpoints. It should be understood that the following distance data mayinclude more data, such as a following duration. The following durationmay include a length of time the gig-economy worker has followed thenext vehicle.

In another example, assume that the computer processor receives a speedassociated with the gig-economy worker's vehicle, and further assumethat the speed is 80 miles per hour (mph). The computer processor mayaccess external data sources (e.g., digital map server 43) and/orutilize image analysis to determine a speed limit associated with thecurrent environment (e.g., current roadway). For example, the computerprocessor may analyze a set of digital images received from an imagingapparatus (e.g., camera 258) to determine an associated speed limit. Thecomputer processor may compare the determined speed limit to thereceived speed of the gig-economy worker's vehicle to determine that thegig-economy worker's vehicle is traveling above the posted speed limit,and should slow down. Correspondingly, the computer processor maydetermine an education point indicating that the gig-economy workershould decrease the speed of the vehicle. Again, an indication of a costassociated with action or inaction may be presented together with theeducation point to the gig-economy worker in some embodiments.

In yet another example, the computer processor may receive data from thegig-economy worker's vehicle indicating historical usage data of thevehicle. The historical usage data may indicate values corresponding tothe past operation of the gig-economy worker's vehicle. The historicalusage data may indicate an average speed of the gig-economy worker'svehicle, an average acceleration of the gig-economy worker's vehicle,and/or any other suitable telematics-based data and/or other suitableindicator. For example, the suitable indicator may also include typicalroutes associated with the gig-economy worker's vehicle. Thus, thesystem of the present disclosure may determine one or more educationpoints corresponding to the historic operation of the gig-economyworker's vehicle as well as education points corresponding to thecurrent operation of the gig-economy worker's vehicle. In someembodiments, costs associated with such education points (e.g.,potential reductions in insurance costs) may be generated for each ofthe education points.

To illustrate, assume the gig-economy worker historically operates thevehicle at speeds in excess of posted speed limits during gigs, and thegig-economy worker is currently driving above the posted speed limitduring a gig. The computer processor may determine one or more educationpoints to mitigate both the speeding behavior currently taking place, aswell as an education point to mitigate the gig-economy worker'scontinued operation of the vehicle above the speed limit.

In certain embodiments, the education model may incorporate a weightedprioritization metric to more accurately determine relevant, succinctrecommendations (e.g., education points). The weighted prioritizationmetric may assign weighting values to the data, and determine anassociated education point based upon the most heavily weighted data.Additionally or alternatively, the weighted prioritization metricincluded in the model may categorize various associations of data, andsubsequently apply weighting values based upon the categorizations. Forexample, the categorizations may include vehicle telematics data,vehicle routing data, upcoming traffic information, current trafficinformation, and/or any other suitable data or combination thereof.Further, the weighted prioritization metric may assign aggregateweighting values to the categorizations based upon the type, amount, orother relevant consideration or combination thereof when assigning theaggregate weighting value to the categorization.

As an example, the weighted prioritization metric may assign a weightedvalue of 95 (on a scale of 0-100) to the vehicle telematics datacategorization if there is data indicating that the gig-economy workeris operating their vehicle more than 20 mph in excess of the postedspeed limit during a gig, and a weighted value of 35 if there is trafficdata indicating a minor traffic slowdown several miles ahead. Thus, thecomputer processor may display an education point corresponding to thegig-economy worker's excessive speed, instead of an education pointdirected to the minor traffic slowdown. Additionally or alternatively,the computer processor may first display the message corresponding tothe excessive speed before transitioning to the message directed to theminor traffic slowdown, reflecting the weighted prioritization. However,it should be understood that the computer processor may display anydetermined education point in any order, regardless of theprioritization, and such display settings may be adjustable by thegig-economy worker.

In any event, the method 600 continues by displaying the education pointto the gig-economy worker (block 614). The computer processor maytransmit the education point to a device located within the gig-economyworker's vehicle for display (e.g., a vehicle display panel), and/or thecomputer processor may execute instructions to display the educationpoint on a display (e.g., display 202).

In certain embodiments, the computer processor may transmit a periodiceducation point for display in the gig-economy worker's vehicle toprovide one or more beneficial driving behaviors intended to positivelyimpact a gig-economy worker's performance during gigs. For example, andas discussed herein, a gig-economy worker may consistently drive overthe speed limit, which may negatively impact their profile rating andtheir potential revenue/profit. Thus, the computer processor maytransmit the periodic education point for display to the gig-economyworker to provide a suggested beneficial driving behavior (e.g., anupdate suggesting that the user slow down).

Additionally, the computer processor may concurrently display apredicted commercial driving profile update/adjustment associated withthe education point. For example, the education point may suggest thatthe gig-economy worker slow down during gigs, and may additionallyindicate that should the gig-economy worker slow down, their associatedcommercial driving profile rating will increase by 5 points. In someembodiments, the updated or adjustment may be determined and presentedin terms of cost or savings associated with actions relating to theeducation point, such as a change in costs associated with a giginsurance policy (either an in-force or hypothetical policy) or a changein the expected value of losses related to the risks associated withaction or inaction on the education point. In this way, the gig-economyworker may receive data upon which to rationally determine how best tooptimize their gig-economy work when risk is considered. In furtherembodiments, an option to obtain a gig insurance policy covering one ormore gigs may be presented to the gig-economy worker for review andacceptance.

Additionally or alternatively, should the gig-economy worker follow thesuggestion made in the education point, the gig-economy worker mayunlock or otherwise access special discounts, features, and/or otherpromotions related to the particular gig-economy platform applicationcurrently in use, a gig insurance policy held by the gig-economy worker,and/or any other suitable business, application, etc. For example, thegig-economy worker may receive discounts at fast food establishments,gas stations, car mechanics, and/or other suitable establishments. Thus,the method 600 may facilitate better driving habits, and the gig-economyworker's subsequent gig performance and overall profitability may beimproved, by linking good driving behavior with monetary incentives. Itis to be appreciated that any suitable scoring system or metric may beused for the profile rating.

Exemplary Methods for Detecting Commercial Driving Activity

Generally speaking, an insurance provider for a gig-economy worker mayconsider and analyze a number of factors when, for example, quoting oroffering an insurance policy to the gig-economy worker, reviewingcoverage provided by an insurance policy for the gig-economy worker,handling an insurance claim, etc. For example, the insurance providermay use movement data and/or other data to associate movements to gigactivities (e.g., commercial activities) and non-gig activities (e.g.,personal activities like shopping, going to an event, going to school,going to work, etc.) at the time of an accident. Such data may be usedto, when an accident occurs, impute the accident to a personal insurancepolicy or to a gig or commercial insurance policy.

In some embodiments, a gig-economy insurance policy may be a limitedinsurance policy that only provides coverage to a gig-economy worker fora loss that occurs while performing a gig-related activity, such as anaccident while providing on-demand transportation services. For example,a gig-economy insurance policy cost may be based upon an amount of timespent driving for gig-economy work, such as a percentage of time spenton gig-related driving, a distance driven while performing gig-economywork, or total hours spent on gig-related driving.

In some embodiments, the amount of gig-related driving may be weighted(e.g., based upon time of day, location, weather conditions, roadconditions, or other factors associated with the gig-related driving) toreflect relative risk levels. For the convenience of gig-economyworkers, telematics or other data may be used to attribute drivingactivity to gigs or to personal driving. For example, the server 40 mayautomatically detect driving activity and attribute such drivingactivity to a first gig, a time between gigs, or to home at the end ofgig activities be attributed to gig-related coverage.

FIG. 7 illustrates a flow diagram of an exemplary automatic gig-economyactivity identification method 700 representative of example processes,methods, logic, software, computer- or machine-readable instructions fordetermining the likelihood that activity (e.g., driving of thegig-economy worker 17) is related to commercial activity or personalactivity at a particular point in time. The processes, methods, logic,software and instructions may be an executable program or portion of anexecutable program for execution by a processor such as the processor 62of server 40. The program may be embodied in software or instructionsstored on a non-transitory computer- or machine-readable storage device,storage medium and/or storage disk associated with the processor 62 inwhich information is stored for any duration (e.g., for extended timeperiods, permanently, for brief instances, for temporarily buffering,and/or for caching of the information).

Although the example program is described with reference to theautomatic gig-economy activity identification method 700, other methodsof detecting whether activity of a person is related to gig-economy workor personal activity may alternatively be implemented based upon thedescription herein. For example, the order of execution of the blocksmay be changed, and/or some of the blocks described may be changed,eliminated, or combined. Additionally, or alternatively, any or all ofthe blocks may be implemented by one or more hardware circuits ormodules structured to perform the corresponding operations, with orwithout executing software or instructions.

The automatic gig-economy activity identification method 700 beginswith, for example, the processor 62 of server 40 waiting to receive data702 representative of the movements of a gig-economy worker and possiblyother gig-economy workers (e.g., the additional gig-economy workers 16)(block 704). In some embodiments, the data 702 may indicate a beginningof a gig-related interaction between the gig-economy worker and acustomer (e.g., one of the gig-economy customers 21). The data 702 mayindicate a location at which a gig-economy worker activated agig-economy platform application on a mobile device (e.g., mobilecomputing device 110), a location at which the gig-economy workeraccepted a gig via a mobile device, locations to which the gig-economywork traveled, etc. The processor 62 receives the data 702representative of one or more movements of the gig-economy worker (block706).

Example data 702 includes: (i) movement data 702A, which may includetelematics data and/or information regarding vehicle operation such as,but not limited to roads traveled, road segments traveled, intersectionstraversed, pathways traveled, locations of stops other than thoseassociated with rules of the road, length of stops, etc.; (ii) log data702B indicating times of certain events; (iii) behavioral data 702Crelating to monitored actions such as driving maneuvers; (iv) gigapplications data 702D stored by one or more gig-economy platformapplications related to the travel of a gig-economy worker in theperformance of gig-related activities; (v) scrapped data 702E scrapedfrom one or more gig-economy platform applications related to the travelof a gig-economy worker in the performance of gig-related activities;(vi) environmental data 702F; and/or (vii) any other available data thatmay be indicative of gig-economy work performance. The data 702, themovement data 702A, the log data 702B, the behavioral data 702C, the gigapplications data 702D, the scraped data 702E, the environmental data702F, and/or other data may be used to associate roads traveled, roadsegments traveled, intersections traversed, pathways traveled, locationsof stops, lengths of stops, etc., with a likelihood of gig-relatedactivity (e.g., commercial activity) compared to non-gig-relatedactivity (e.g., personal activity).

Any or all of the data 702 (i.e., data 702A-702F) may be collected orgenerated with one or more sensors of a mobile device, one or moresensors of a vehicle (e.g., internal sensors 108 or external sensors 120associated with the vehicle 10) communicatively coupled to an on-boardcomputer of the vehicle (e.g., the on-board computer 11A of the vehicle10), a computing device within or connected to the vehicle (e.g., amobile computing device 110, such as a user mobile device 12), a GPSdevice, and/or any other means to track, store and recall relevant data.The data 702 may, in some examples, include historical data forcomparison or establishing a baseline of non-gig-related drivingactivity. In some examples, the data 702 includes data related to themovements of other gig-economy workers (e.g., additional gig-economyworkers 16 associated with additional vehicle 15), which may be used toclassify a gig-economy worker's movements as being gig-related or as notbeing gig-related.

Example movement data 702A includes data indicative of locations ormovements, which may include roads traveled, road segments traveled,intersections traversed, pathways traveled, turns made, locations ofstops other than those associated with rules of the road, length ofstops, time of data associated with driving events, etc.

Example log data 702B includes times and locations associated withevents, which may include times and places of gig starts, durations andplaces of gig stops. Log data 702B may be generated and/or storedautomatically and/or manually on, for example, a mobile device. In someembodiments, log data 702B may include gig-economy worker indications ofstart and stop times of gig-economy work for purposes of using a giginsurance policy. In further embodiments, the log data 702B may includeautomatically generated log entries, such as entries of vehicle start-upand shut-down events.

Example behavioral data 702C includes data indicative of behaviors thatmay be associated with gig-economy work, which may include speed datasuch as acceleration and/or deceleration rates, speed relative to postedspeed limit, braking data such as braking speed and/or distance,risk-adverse driving data such as less aggressive acceleration andbraking, handling data such as aggressive or tight turning, etc. Any orall of the behavioral data 702C may be used to help identify gig ornon-gig activity when driving behavior differs between gig and non-gigactivity.

Further example behavioral data 702C includes, but is not limited to,the speed at which the gig-economy worker typically drives whenperforming gig-related activities; the type of vehicle that thegig-economy worker typically drives during gig-related ornon-gig-related activities; the type of roads or routes that thegig-economy worker usually takes during gig-related or non-gig-relatedactivities; the distance at which the gig-economy worker typicallytrails other vehicles during gig-related or non-gig-related activities;whether the gig-economy worker drives a large percentage of timeadjacent to other vehicles traveling in the same direction (such as on afour-lane highway) during gig-related or non-gig-related activities;whether the gig-economy worker typically drives too slow or too fast inrelation to the posted speed limit during gig-related or non-gig-relatedactivities; and/or other driving behaviors of the gig-economy workerduring gig-related or non-gig-related activities.

Similarly, the other data may indicate the weather conditions that thegig-economy worker will normally drive in during gig-related ornon-gig-related activities; the locations where the gig-economy workertypically drives during gig-related or non-gig-related activities;and/or the dates/times of day that the gig-economy worker usually drivesor drives the most at during gig-related or non-gig-related activities.

Example gig applications data 702D includes data associated with agig-economy worker's gig-related applications, such as data captured bygig-economy platform applications. Such gig-related applications mayinclude third-party applications used to enhance the experience of thegig-economy worker, such as mapping applications or insurance-relatedapplications.

Example scraped data 702E includes data captured for each gig, such ascustomer, start and/or stop, type of gig, etc., stored by, for example,a company operating an interface (e.g., a website) for a gig-economyworker to identify and select gigs. Data related to the posting andassignment of gigs can be scraped from such websites or other interfacesof gig-economy platforms.

Example environmental data 702F includes data associated with the localenvironment in which a gig is performed, such as local weather orinfrastructure conditions. The environmental data 702F may be capturedby, for example, public and private surveillance cameras, toll plazas,swiping on access cards, etc.

While examples described herein relate to automobiles, they may be usedin connection with, for example, bicycles, motorcycles, scooters, hoverboards, skateboard, drones, autonomous vehicle, smart car, planes,trains, subways, buses, walking, running and/or any other means that canbe used to perform gig-related activities and personal activities.

In any event, as data 702 is received (block 706), the method 700continues by processing the incoming data 702 for storage in a database708 (block 710), which database 708 may comprise one or more databases46. In one example, for each person, data is stored in the database 708as a sequence of entries, where each entry includes (i) an identifierfor a traveled segment, intersection, path, location, etc., (ii) a starttime, (iii) an end time, (iv) a type (e.g., gig or non-gig) for theentry, if known, etc., and/or (v) an identifier for the gig-economyworker associated with the entry. In some examples, the gig or non-gigtype of activity (or a likelihood of gig or non-gig activity) isdetermined using the behavioral data 702C.

To determine likelihoods of commercial activity, the automaticgig-economy activity identification method 700 operates a classifier 53(see FIG. 1A) to determine the likelihoods of observed activity beingeither gig activity or non-gig activity (block 712). In the example ofFIG. 1A, the classifier 53 is or may include a portion of a memory unit(e.g., the program memory 60) configured to store software, and machine-or computer-readable instructions that, when executed by a processingunit (e.g., the processor 62) cause the processing unit to perform aclassification of data into gig-related activity or non-gig-relatedactivity (block 712). In some examples, the classifier 53 determines thelikelihoods that traversals of trip segments (e.g., a section oftraveled road, a section of traveled pathway, an intersection, astopping point, a point-of-interest) are attributable with gig-relatedactivity (e.g., commercial driving activities) or to non-gig activity(e.g., personal driving activities).

In some examples, the classifier 53 utilizes, applies, or implements amachine-learning model 54 to process data stored in the database 708 todetermine (e.g., estimate, generate, calculate, etc.) likelihoods thatmovements are gig-related. The machine-learning model 54 may utilizedeep learning algorithms that are primarily focused on, for example,pattern recognition, and may be trained by processing example data. Themachine-learning model 54 may include Bayesian program learning (BPL),voice recognition and synthesis, image or object recognition, opticalcharacter recognition, and/or natural language processing—eitherindividually or in combination. The machine-learning model 54 may alsoinclude natural language processing, semantic analysis, automaticreasoning, and/or machine-learning. The machine-learning model 54 and/orthe classifier 53 may be implemented by the server 40 as a set oflogical instructions executed as machine- or computer-readableinstructions to implement the classifier 53 and/or the machine-learningmodel 54.

As previously mentioned, the classifier 53 may utilize, apply, orinclude machine-learning to adaptively learn to attribute movements withgig- and non-gig-related activities. Generally, machine-learning mayinvolve identifying and recognizing patterns in existing data such asthe data 702 in order to facilitate making predictions for subsequentdata 702. The machine-learning model 54 may be created usingunsupervised and/or supervised machine-learning. In supervised learning,one or more processing elements are provided with example inputs andassociated known or true outputs, and may seek to discover a generalrule that maps inputs to outputs, so that when subsequent novel inputsare provided, the processing element may, based upon the discoveredrule, accurately predict the correct or a preferred output. Inunsupervised machine-learning, the processing element may be required tofind its own structure in unlabeled example inputs. In some embodiments,machine-learning techniques may be used to determine likelihoods thatmovements are attributable with commercial activity from the data 702.

As received data 702 is processed and stored in the database 708 (block710), it is determined whether the classifier 53 has been trained or isstill being trained (block 714). For example, if a machine-learningmodel 54 of the classifier 53 is still being trained, input vectors areformed (block 716). In some examples, the input vectors are the same asthe data stored in the database 708. The classifier 53 is trained bycausing the classifier 53 to train, test and validate a machine-learningmodel 54 of the classifier 53. In some examples, as new data 702 isreceived, the new data 702 and, in some instances, previous data storedin the database 708, is used to train the classifier 53 by performing aclassifier training iteration (block 718) to train the machine-learningmodel 54. The iteratively trained machine-learning model is then used tooperate the classifier 53 to generate output classifications 720 (block712). Output classifications 720 of the classifier 53 during trainingare compared with actual gig or non-gig data to form errors that areused to develop and update the machine-learning model 54.

In some examples, data stored in the database 708 is used repeatedly totrain a machine-learning engine of the classifier 53 until themachine-learning model 54 has converged. For example, until theclassifier 53 is classifying travel segment transversals as gig ornon-gig correctly with a predetermined threshold level of accuracy. Insome examples, convergence of the machine-learning model 54 is performedusing k-fold cross-validation. The data stored in the database 708 israndomly split into k parts (e.g., 5 parts), and the machine-learningmodel 54 of the classifier 53 is trained using k−1 parts of the k partsof the database 708 to form trial segment traversal likelihoods. Themachine-learning model 54 is evaluated using the remaining one part ofthe database 708 to which the machine-learning model 54 has not beenexposed.

Outputs of this developing machine-learning model 54 for the database708 are compared to actual or known likelihoods to determine theperformance or convergence of developing machine-learning model 54.Performance or convergence can be determined by, for example,identifying when a metric computed over the errors (e.g., a mean-squaremetric, a rate-of-decrease metric, etc.) satisfies certain criteria(e.g., a metric is less than a predetermined threshold, such as a rootmean squared error).

Returning to block 714, if the machine-learning model 54 of theclassifier 53 is determined to have been trained (block 714), inputvectors are formed (block 722). In some examples, the input vectors arethe same as the data stored in the database 708. The new data from thedatabase 708 is classified (block 724) by processing the data with theclassifier 53 (block 712), and the output classifications 720 of theclassifier 53 are used to attribute travel segments of the new data 702to gig activities (e.g., commercial activities) or non-gig activities(e.g., personal activities).

In some examples, the machine-learning engine of the classifier 53 is atleast partially or initially training using data 702 for a gig-economyworker that is known to be (e.g., indicated by the gig-economy worker)as being unrelated to gig-economy work, such as data provided by thegig-economy worker regarding driving prior to starting work as agig-economy worker. Subsequent gig and non-gig activities could be usedto further train the machine-learning model 54 and/or to test themachine-learning model 54.

In some examples, the machine-learning model 54 of the classifier 53 isadditionally trained using data 702 for other gig-economy workers. Suchdata may be applicable when there are number of gig-economy worker in asame geographic area that likely have similar gig driving patterns. Suchdata may be used, for example, to determine an initial likelihood ofgig-related activity, which may be further refined using data specificto a particular gig-economy worker.

Exemplary Gig-Economy Data Model Generation

The methods and systems described herein may facilitate gig-economy datacollection and analysis, which may be used to model and predict variousmetrics related to gig-economy work. As described further below, datamodels may be generated and used to produce recommendations forgig-economy workers to optimize their work. Currently, optimization ofgig-economy work is limited to improvements in the efficiency ofperforming a task after accepting it (e.g., more efficient on-demandride or delivery routes) or individual determinations of when to workbased upon lagging signals of demand (e.g., notifications of currentsurge rates going into effect after a rapid increase in demand relativeto supply). More robust data models are needed for accurate predictionof demand and profitability. Additionally, the robust data modelsdescribed herein enable optimization based upon worker-specifiedcriteria, such as a gig-worker schedule, current or future locations, orgig preferences. By modeling gig metrics relating to a plurality ofgig-economy platforms, the techniques described herein also enableoptimization recommendations to be generated between different gigs ofdifferent types or on different gig-economy platforms. The methodsdescribed herein solve the problems of insufficient predictive power inthe existing techniques of gig-economy work evaluation and optimizationby generating and using data models of gig metrics for comparison andoptimization of gigs according to various criteria in view of current orexpected conditions.

FIG. 8 illustrates a flow diagram of an exemplary gig-economy data modelgeneration method 800 for training gig-economy data models using datarelating to a plurality of gigs performed by a plurality of gig-economyworkers. The data may be associated with gigs created and performedthrough a plurality of gig-economy platforms, such as on-demand servicesnetwork platforms 70. In some embodiments, one or more gig-economy datamodels may be generated for each gig-economy platform to facilitatecross-platform comparison and optimization recommendations. The method800 may be performed by the one or more processors of one or moreservers 40 implementing executable instructions stored ascomputer-readable instructions stored in the one or more programmemories 60. In order to obtain gig data for processing, the one or moreservers 40 may communicate with a plurality of front-end components 2 orother back-end components 4 via the network 3. In alternativeembodiments, similar computer-implemented methods of generatinggig-economy data models may be performed, which may include additional,alternative, or fewer aspects to those described below.

The exemplary gig-economy data model generation method 800 may beginwith collecting gig data associated with a plurality of gigs performedby a plurality of gig-economy workers over a period of time (block 802).The gig data may be pre-processed to generate a set of gig recordscontaining a gig record for each gig in the gig data (block 804), whichgig records may include both gig metrics extracted from the gig data andgig metrics calculated from the gig data. This set of gig records maythen be used to generate gig-economy data models by selecting a machinelearning model to train (block 806), training the model with a firstsubset of the gig records (block 808), and validating the model using asecond subset of the gig records (block 810). Training and validationmay be performed iteratively until the model performance is determinedto be sufficient (block 812). Additional models may then be selected andsimilarly trained (blocks 806-812) until no further models remain to betrained (block 814).

At block 802, the server 40 may collect gig data relating to a pluralityof gigs performed by a plurality of gig-economy workers. The gig datamay include details relating to the gig and its performance, such as acategory of the gig (e.g., on-demand transportation, package delivery,home maintenance tasks, office tasks, or construction tasks), timesassociated with the gig (e.g., time gig offer created, time gigaccepted, time performance started, or time completed), locationsassociated with the gig (e.g., project location, pick-up location,drop-off location, or waypoints), details associated with gigperformance (e.g., performance requirements or specific instructions),ratings associated with the gig (e.g., ratings by gig-economy workers orcustomers), financial information (e.g., total gig payment by customer,gig payment received by gig-economy worker, pricing levels or modifiersin effect for the gig, or out-of-pocket costs associated with thegig—such as parking or roadway tolls), and/or other gig-related dataproviding details regarding the gig.

In some embodiments, some or all of the gig data may be collected bycommunication with one or more gig-economy platforms, such as on-demandservices network platforms 70. In further embodiments, some or all ofthe gig data may be collected from mobile computing devices 110associated with a plurality of gig-economy workers (e.g., on-boardcomputer 11, user mobile device 12, wearable computing device 13, oradditional mobile devices 15).

In some embodiments, data may be collected from other network-connectedcomputing devices, such as customer computing device 20, connected homedevices 22, or autonomous devices 30. In additional embodiments, theserver 40 may collect condition data associated with gigs fromadditional data sources, such as data regarding weather conditions,traffic conditions, special events (e.g., holidays, parades,conventions, sporting events, concerts, or other events affecting alarge number of people), and/or other relevant information that mayimpact supply or demand for gig-economy services.

In yet further embodiments, telemetric data may be collected fromgig-economy workers during gig work, such as through a specializedsoftware application installed by the interested gig-economy workers tobetter track their gig-economy activities for recordkeeping, tax, orprofit optimization purposes. Such telemetric data may include, forexample, metrics regarding vehicle movement during a gig, which may haveimplications for vehicle maintenance costs, customer satisfaction, andworker satisfaction related to the gig.

At block 804, the server 40 may organize the collected data into a dataset of standardized data for analysis by generating a gig recordcontaining gig metrics for each of the gigs indicated in the collectedgig data. Thus, the server 40 may identify each unique gig in the gigdata to avoid duplication and may combine data from various sources intoeach gig record (e.g., customer and gig-worker ratings for the same gigmay be matched and included in the gig record for that gig).

In addition to gig metrics that may be directly extracted from the gigdata (e.g., times, locations, prices, platforms, ratings, or the like),the server 40 may determine additional gig metrics associated with thegig records. The additional gig metrics may include standardizedcategorization of gig data, such as adding entries for a category ofgig-economy service involved (e.g., on-demand transportation, productdelivery, defined scope office work, home project assistance, or movingassistance). For some gigs, such categories may be determined based uponthe associated gig-economy platform.

The additional gig metrics may similarly include gig metrics calculatedfrom the available data to provide more useful data points for analysis.Such calculated gig metrics may include metrics such as total cost inperforming a gig (e.g., by combining direct out-of-pocket costs withindirect costs, such as fuel costs, wear, and maintenance costs forvehicle use based upon time and distance traveled) or profit per unittime for a gig, which may include or exclude indirect costs ofperforming the gig. Such calculated gig metrics may be of particularinterest to gig-economy workers and may thus be useful in trainingmodels for optimization of gig-economy work decisions. In someembodiments, gig metrics may be calculated for related groups of gigs,such as total profit (net or gross) for a gig-economy worker over aperiod of time (e.g., over the course of a day) during which thegig-economy worker completed multiple gigs. Such gig metrics may thatlink multiple gig records in a useful manner.

Once the gig data set has been prepared by generating the set of gigrecords, the server 40 may select a machine learning model to trainusing the gig records at block 806. The machine learning model may beselected for supervised or unsupervised learning. For example,unsupervised learning may be used for identifying unexpectedrelationships between gigs, while supervised learning may be used totrain models for optimization of salient gig metrics, such asprofitability.

A model may be specified based upon user input specifying relevant gigmetrics as predicted variables and other variables as potentialexplanatory variables. For example, a model may be specified to predictthe profit per unit time or the total profit using the remaining gigmetrics. Conditions for training the model may likewise be selected,such as limits on model complexity or limits on model refinement past acertain point. Due to the limitations and differences of the gig dataavailable for different gig-economy platforms, one or more models may beselected for specific platforms. Because gig outcomes vary significantlyby location and time, the models may be selected also based uponlocation (e.g., state or metropolitan area) or time (e.g., weekdays orweekends). In some embodiments, unsupervised machine learning techniquesmay be used to determine the relevant geographic location or timegroupings based upon the gig records.

Thus, the gig-economy data model generation method 800 may begin withselecting machine learning models to identify relevant groups of gigrecords for further analysis, then train models relating to selected gigmetrics based upon the identified groupings of the gig records. This maybe particularly useful for continuous variables such as time andlocation, where clear delineations may not be readily apparent to humananalysts, and which stand in contrast to discrete variables such as thegig-economy platform associated with the gig record.

At block 808, the selected model may be trained using a first subset ofthe gig records to generate a trained model. The selected model may betrained using appropriate machine learning techniques, based upon thetype of model selected and any conditions specified for training themodel. The model may be trained using a supervised or unsupervisedmachine-learning program or algorithm. The machine-learning program oralgorithm may employ a neural network, which may be a convolutionalneural network, a deep learning neural network, or a combined learningmodule or program that learns in two or more features or featuredatasets in a particular areas of interest. The machine-learningprograms or algorithms may also include natural language processing,semantic analysis, automatic reasoning, regression analysis, supportvector machine (SVM) analysis, decision tree analysis, random forestanalysis, K-Nearest neighbor analysis, naïve Bayes analysis, clustering,reinforcement learning, and/or other machine-learning algorithms and/ortechniques.

Machine-learning may involve identifying and recognizing patterns inexisting data in order to facilitate making predictions for subsequentdata. In some embodiments, due to the processing power requirements oftraining machine learning models, the selected model may be trainedusing additional computing resources (e.g., cloud computing resources)based upon data provided by the server 40.

At block 810, upon generation of the trained model, the trained modelmay be validated using a second subset of the gig records to determinemodel accuracy and robustness. Such validation may include applying thetrained model to the gig records of the second subset of gig records topredict values of some of the gig metrics of such records based uponvalues of other gig metrics of the records. The trained model may thenbe evaluated at block 812 to determine whether the model performance issufficient based upon the validation stage predicted values. Thesufficiency criteria applied may vary depending upon the size of the gigdata set available for training, the performance of previous iterationsof trained models, or user-specified performance requirements.

When the server 40 determines the trained model has not achievedsufficient performance, additional training may be performed at block808, which may include refinement of the trained model or retraining ona different first subset of the gig records, after which the new trainedmodel may again be validated at block 810. When the server 40 determinesthe trained model has achieved sufficient performance at block 812, thetrained model may be stored for later use, and the gig-economy datamodel generation method 800 may continue. In some embodiments, trainedgig-economy data models may be stored in the database 46 associated withone or more servers 40.

At block 814, after training a model using the gig records, the server40 may determine whether there remain additional models to train. Suchadditional models may be related to other gig-economy platforms, gigcategories, location groups, or time groups. In some embodiments,additional divisions of the gig records may be used to determine furthermodels to be trained, which may depend upon the availability ofsufficient gig records for the additional divisions. For example, atrained model may be generated for the entirety of a metropolitan areaas a relatively generic model when a more specific model cannot begenerated for some areas within the metropolitan area with small numbersof gig records, while more specific models may also be generated forareas within the metropolitan area for which sufficient gig records areavailable. When the server 40 determines that no further models remainto be trained, the gig-economy data model generation method 800 ends.

Exemplary Gig Optimization Recommendation Methods

The data models generated based upon gig data as discussed above or byother methods may further be used to generate real-time or advancerecommendations for optimizing aspects of gig-economy services bygig-economy workers. In contrast to the limited means of optimizinggig-economy work based upon individual experience or lagging indicatorsof demand, the methods described below generate optimizationrecommendation based upon predictions of expected demand, as well asexpected characteristics of gigs predicted to be available. Thus, thepredictive methods described herein enable optimization of relevant gigmetrics, rather than simply providing a lagging indication of currentoverall demand on a particular gig-economy platform. Such methods solvethe problems of insufficient predictive power and worker-specificcustomization in the existing techniques of gig-economy work evaluationand optimization by using data models of gig metrics for comparison andgeneration of optimization recommendations according to various criteriain view of current or expected conditions.

FIG. 9 illustrates a flow diagram of an exemplary optimizationrecommendation generation method 900 for providing gig-economy workerswith recommendations for optimizing gig-economy work based upongig-economy data models. Gig-economy work recommendations may includerecommendations relating to timing, location, or type of gigs to pursuein order to maximize or minimize gig-economy optimization criteria, suchas total profit, profit per unit time, or travel distance. By usinggig-economy data models generated for a plurality of gig-economyplatforms, such as on-demand services network platforms 70, theoptimization recommendations may also enable gig-economy workers toshift their efforts between different categories or types of gig-economywork in response to demand.

The optimization recommendations may be generated by one or more servers40 implementing executable instructions stored as computer-readableinstructions stored in the one or more program memories 60. In order toobtain relevant optimization criteria or condition data, the one or moreservers 40 may communicate with a plurality of front-end components 2 orother back-end components 4 via the network 3. In alternativeembodiments, similar computer-implemented methods of generating gigoptimization recommendations may be performed, which may includeadditional, alternative, or fewer aspects to those described below.

The exemplary optimization recommendation generation method 900 maybegin with receiving an indication of a triggering event to generateoptimization information (block 902). In response to such indication,gig optimization criteria may be determined (block 904), and one or morerelevant gig-economy data models may be accessed (block 906). In someembodiments, additional condition data may be determined in order toproduce accurate optimization information (block 908). Using the one ormore gig-economy data models, the gig optimization criteria, and (whereavailable) the additional condition data, gig optimization data is thengenerated (block 910), which may include gig optimizationrecommendations for a particular user, location, or time. Arepresentation of such gig optimization data may then be presented to agig-economy worker or other user (block 912). In some embodiments, theuser may enter input associated with one or more gig optimizationrecommendations presented or sought (block 914). In response to suchinput, gig metrics associated with the gig optimization recommendationsmay be predicted (block 916) and presented to the user (block 918).

At block 902, the server 40 may receive an indication of a triggeringevent to cause the generation of gig optimization information. In someembodiments, the triggering event may be a user request from a mobilecomputing device 110 associated with a gig-economy worker 17 (e.g., theuser mobile device 12). In further embodiments, the triggering event maybe automatically generated based upon user-specific information, such asupon a gig-economy worker 17 opening an application associated withgig-economy work on a user mobile device 12, upon the gig-economy worker17 indicating availability for gigs in such an application, uponcompletion of a gig by the gig-economy worker 17, or periodically duringgig-economy work availability by the gig-economy worker 17. For example,a gig-economy worker 17 may access a gig optimization dashboardapplication on the user mobile device 12 to view current or future gigoptimization data, which may include user-specific gig optimizationrecommendations.

As another example, the triggering event may be a determination that agig-economy worker 17 is currently engaged in gig-economy driving,rather than personal driving, as discussed above. In yet furtherembodiments, the triggering event may be an event unassociated with aspecific user, such as upon the passage of a predetermined time periodor upon the availability of new condition data or new gig-economy datamodels. In such embodiments, the resulting gig optimization data may bestored for presentation to multiple users.

At block 904, the server 40 may determine gig optimization criteriaindicating the parameters of the optimization. Such optimizationcriteria may be associated with one or more gig metrics to be optimized,as well as gig metrics indicating constraints on the optimization (e.g.,location, time, or categories of gigs to be performed). For example, netprofit and net profit per hour may be determined to be gig metrics to beoptimized, while geographic area and time range may be constraints onthe optimization. Thus, the optimization may be limited to conditionsrelevant to a particular gig-economy worker at a particular time,providing more accurate gig optimization recommendations.

In some embodiments, optimization criteria may be determined based uponindications of such criteria included in a request from a mobilecomputing device 110. For example, a user request may indicateuser-defined optimization criteria such as a time range, location range,or preferred gig-economy platforms for gig work.

In further embodiments, the server 40 may obtain schedule or preferencedata relating to a gig-economy work, such as in a user profile generatedby the user or generated from data the user has granted permission toaccess. For example, a user schedule may be used to determine locationsand times to use as optimization criteria, such as a home or officelocation to which the user will travel after completion of gig-economywork, which may be used to reduce uncompensated travel related to gigsperformed by a user (e.g., travel to or from a location before or aftercompleting a gig).

As another example, user preference data may indicate a user-specifiedranking or rating of gig-economy platforms or categories of gig-economywork, which may be used to weight the gig optimization recommendationsin favor of preferred gig types. In some embodiments, default values ofcertain gig optimization criteria may be used when other optimizationcriteria are not specified, such as a current time determined at theserver 40 or a geographic area associated with a user based upon pastgigs performed by the user.

At block 906, the server 40 may select and access one or moregig-economy data models based upon the gig optimization criteria. Thismay include matching the optimization criteria with model specificationsof previously trained models stored in a database 46 to select one ormore gig-economy data models that may be relevant to optimization.

In some embodiments, gig-economy data models meeting only some of thegig optimization criteria may also be selected for use in generating gigoptimization recommendations or comparison points concerning adjustingthe gig optimization criteria. For example, models for different timesof day or nearby locations outside a specified geographic area may beselected and accessed to generate and present alternative gigoptimization data regarding alternative gig-economy work conditions thatmay be of interest to a user, such as alternative recommendations toperform gig-economy work at a different time of day. Such alternativegig optimization data may be presented in addition to gig optimizationdata based upon matching all the gig optimization criteria, therebyproviding a useful comparison regarding the benefit or detriment fromadjusting the optimization criteria. The selected gig-economy datamodels may then be accessed by the server 40 from the database 46.

At block 908, in some embodiments, the server 40 may determineadditional condition data to use in the optimization. Such additionalcondition data may include current or predicted conditions that affectsupply, demand, or performance of relevant gigs. For example, inclementweather typically increases demand for on-demand transportation, as wellas increasing time to complete such gigs. In contrast, inclement weatheris usually uncorrelated with package delivery. Therefore, current orpredicted weather conditions may be determined by the server 40 when atleast one of the gig-economy data models uses weather conditions as apredictive variable. Additional condition data may include conditionssuch as weather conditions, traffic conditions, local events, estimatesof demand, or estimates of supply by other gig-economy workers. Thus,the server 40 may obtain additional condition data from one or moregig-economy platforms via network 3, such as by communication with atransaction server 42, task management server 44, or fleet managementserver 45.

In some embodiments, additional condition data may be obtained fromcustomer devices, such as customer computing devices 20, connected homedevices 22, or autonomous devices 30. Such additional condition data maybe indicative of current user-specified or automated gig requests, or itmay be indicative of future demand for gig-economy services.

At block 910, the server 40 may apply the optimization criteria and anyadditional condition data to the one or more gig-economy data models togenerate gig optimization data. Such gig optimization data may includeexpected values of gig metrics to be optimized for each model, as wellas ranges of the gig metrics. Values of gig metrics to be optimized maybe determined for each of a plurality of combinations of modelpredictive variables, including variables not associated with the gigoptimization criteria. For example, a plurality of locations within ageographic area to wait for a gig may be used as input values for agig-economy data model to obtain corresponding output values of expectednet profit, thereby allowing a comparison of different waiting locationsbased upon their expected impact on profitability. By calculating thevalues of output gig metrics for each of a plurality of input variablesand/or a plurality of gig-economy data models, the output gig metricsmay be compared to identify optimal gig parameters.

In some embodiments, the optimal gig parameters may account for riskassociated with various gigs, which may vary by gig type, time, orlocation. Such risk may be considered as a cost associated with thegig-economy work, either as a direct cost (e.g., a cost of a short-termor supplemental insurance policy) or as an indirect cost (e.g., anexpected value of losses associated with such risk).

In further embodiments, optimal gig parameters may be further used togenerate gig optimization recommendations that may be implemented by agig-economy worker to optimize the outcomes of gig-economy work. Forexample, a gig optimization recommendation may indicate switching fromproviding on-demand travel services to providing on-demand officeservices is expected to result in an increase in net profit betweencertain times of day, while the reverse may be optimal during at othertimes, based upon predicted values of gig metrics calculated using thegig-economy models. In some embodiments, a plurality of potential gigoptimization recommendations associated with a plurality of gigparameters may be generated, while a subset of such potential gigoptimization recommendations may be selected as the gig optimizationrecommendations based upon their relative impact on the expected valuesof gig metrics to be optimized.

At block 912, the server 40 may cause a representation of at least someof the gig optimization data to be presented to a user via a display 202of a mobile computing device 110. In some embodiments, therepresentation of the gig optimization data may comprise one or more gigoptimization recommendations, which recommendations may be associatedwith various conditions (e.g., times or geographical areas). In furtherembodiments, the representation may include a visual presentation of thegig optimization data outputs relative to input values, such as atabular presentation of predicted profit for each a plurality of hoursor a heat map showing the predicted profitability or waiting time forgigs at various locations within a geographic area. In some embodiments,a dashboard of gig optimization data may be presented to the user tomake multiple decisions, such as a gig-economy platform to use and alocation at which to offer gig-economy services. When a gig optimizationrecommendation is to be presented to the user, in some embodiments, arepresentation of such recommendation may be presented as an alert orpush notification on the mobile computing device 110 associated with theuser.

In some embodiments, one or more options may be presented to the userfor selection or input, such as options relating to gig optimizationcriteria. Such options may be presented to the user to enable the userto compare various scenarios by adjusting the optimization criteria.

At block 914, in some embodiments, the server 40 may receive from amobile computing device 110 via the network 3 one or more indicators ofuser input related to the gig optimization criteria options. Such userinput may indicate selection of options regarding gig metrics to beoptimized, gig metrics used as input by the models, or gig metrics usedin determining which gig-economy data models to apply. For example, theuser input may indicate a new category of gig-economy work or a newgig-economy platform to analyze. In some embodiments, the user input maybe received as values or selections used to generate one or more outputgig metric values as an interactive gig metric calculator. In suchembodiments, predicted values of certain user-specified or predeterminedoutput gig metrics (e.g., gig metrics related to profit or cost) may beupdated in real time in response to user input indicative of input gigmetrics (e.g., gig metrics related to time, location, or type of gig).

At block 916, in some embodiments, the server 40 may determine one ormore predicted values of the gig metrics based upon the user input andthe gig-economy data models. In some instances, the server 40 may selectand access additional gig-economy data models based upon the user input,such as in cases when the user input changes gig metric values that wereused to select the one or more gig-economy data models previously usedin generating the gig optimization data. Thus, the user input may beused to generate updated gig optimization data according to thepreviously identified gig-economy data models or additional gig-economydata models. In some embodiments, the user input may be used to generateone or more gig optimization recommendations for the user, which may bethe same as or differ from previously generated gig optimizationrecommendations.

At block 918, in some embodiments, the server 40 may then cause arepresentation of the determined gig metric values or gig optimizationrecommendations to be presented the user via the display 202 of themobile computing device 110. The representation may likewise include oneor more options for the user to input or select further gig optimizationcriteria for further analysis, in which case further gig optimizationdata or recommendations may be generated and presented to the user. Whenno further user input is received, the optimization recommendationgeneration method 900 may end.

FIG. 10 illustrates a flow diagram of an exemplary real-timeoptimization recommendation generation method 1000 for providinggig-economy workers with gig optimization recommendations based upongig-economy data models and current conditions. The gig optimizationrecommendations may be generated in a manner similar to the gigoptimization recommendations discussed above. However, using currentconditions has the advantages of providing immediately actionablerecommendations and of reducing or eliminating the need for user input.

By using gig-economy data models generated for a plurality ofgig-economy platforms, such as on-demand services network platforms 70,the optimization recommendations may also enable gig-economy workers toshift their efforts between different categories or types of gig-economywork in response to current demand. The gig optimization recommendationsmay be generated by one or more servers 40 implementing executableinstructions stored as computer-readable instructions stored in the oneor more program memories 60.

In order to obtain current condition data, the one or more servers 40may communicate with a plurality of front-end components 2 or otherback-end components 4 via the network 3. In alternative embodiments,similar computer-implemented methods of generating gig optimizationrecommendations may be performed, which may include additional,alternative, or fewer aspects to those described below.

The exemplary real-time optimization recommendation generation method1000 may begin with receiving an indication of a triggering event togenerate gig optimization recommendations (block 1002). In response tosuch indication, relevant current conditions may be determined (block1004), and gig optimization criteria may be determined (block 1006).Based upon the gig optimization criteria and current conditions, one ormore relevant gig-economy data models may be accessed (block 1008) andused to generate one or more gig optimization recommendations for theuser (block 1010).

In some embodiments, the one or more gig optimization recommendationsmay then be presented to the user (block 1014). In other embodiments,the one or more gig optimization recommendations may be evaluated todetermine whether present any of the gig optimization recommendations tothe user (block 1012), following which one or more gig optimizationrecommendations may be presented to the user (block 1014) in someinstances. In further embodiments, one or more of the gig optimizationrecommendations may be implemented automatically (block 1016), with orwithout user verification or notification.

At block 1002, the server 40 may receive an indication of a triggeringevent to cause the generation of gig optimization recommendations. Theindication of the triggering event may be received from a mobilecomputing device 110 (e.g., an on-board computer 11, a user mobiledevice 12, or a wearable computing device 13) associated with a user(e.g., a gig-economy worker 17). In some embodiments, the indication ofthe triggering event may be received from a gig-economy platform, suchas a server of an on-demand services network platform 70. In furtherembodiments, the server 40 may automatically generate the indication ofthe triggering event based upon information available at the server 40(e.g., passage of a predicted time duration associated with an expectedrequired to complete a current gig) or based upon information receivedfrom other data sources via the network 3.

The triggering event may be an event or action indicating the user iscurrently available to accept a new gig or will be available in a shorttime. Thus, the triggering event may include any of the following: theuser signing in to a gig-economy application on the mobile computingdevice 110, the user status changing from unavailable to available in agig-economy application, the completion of a gig, or the user locationbeing within a threshold distance of a completion location of a gig.Thus, the triggering event may be associated with a time at which a usercould reasonable taken actions to follow a recommendation, therebyproviding real-time guidance to the user at an appropriate time.

At block 1004, the server 40 may next determine current conditionsrelated to gig-economy work. In some embodiments, the current conditionsmay be determined based upon data received from the user via the network3, as well as additional data from other data sources. Such currentcondition data may include the current location of the user, an expectedcompletion location of the user upon completion of a current gig, userschedule data (e.g., upcoming schedule blocks or associated locations),current vehicle fuel levels, or other user-specific data that may affectthe gig optimization recommendations for the user at a particular time.Such additional data from other data sources may include, for example,demand data from customer computing devices 20, demand or result datafrom connected home devices 22, demand or supply data from autonomousdevices 30, current gig-economy market data from one or more gig-economyplatforms (e.g., supply or demand data from on-demand services networkplatforms 70), external condition data (e.g., weather conditions,traffic conditions, or data regarding local events), or other similardata not specific to the user.

In addition, general condition data not specific to the current time maybe determined, such as general user preferences or skills possessed bythe user. In some embodiments, the server 40 may generate values of somecurrent conditions from received current condition data, such as bycalculating a distance of the user from a destination location (e.g., ahome or worksite location), a time spent performing gig-economy work, ora time remaining until a scheduled event (e.g., a time the user hasscheduled as being unavailable for gig-economy work).

At block 1006, the server 40 may determine optimization criteria forgenerating gig optimization recommendations. Such optimization criteriamay be based upon general user preferences (or general defaultpreferences, such as net profit optimization). In some embodiments, theoptimization criteria may be based in whole or part upon the currentconditions, such as by determining optimization criteria indicatingpreference for completing a gig near a location or by a target time.Some optimization criteria may be based upon a combination of currentcondition data and general condition data, such as a user preference toavoid certain routes or areas during inclement weather. In someembodiments, optimization criteria may be associated with current risklevels, such as by adjusting net profit to account for increased riskduring high-risk times or at high-risk locations (e.g., busy touristareas during inclement weather). Thus, the cost of additional riskassociated with gig-economy work may be included in the optimizationprocess, either as an indirect cost (e.g., an expected value ofpotential losses) or as a direct cost (e.g., a cost for increased orshort-term insurance coverage to protect against potential losses).

At block 1008, the server 40 may select and access one or moregig-economy data models to use in generating gig optimizationrecommendations based upon the optimization criteria and the currentcondition data. The gig-economy data models may be accessed by theserver 40 from the database 46. This may include matching theoptimization criteria with model specifications of previously trainedmodels stored in a database 46 to select one or more gig-economy datamodels that may be relevant to optimization. In some embodiments, asdiscussed above, gig-economy data models meeting only some of the gigoptimization criteria may also be selected for use in generating gigoptimization recommendations or comparison points concerning adjustingthe gig optimization criteria.

At block 1010, the server 40 may apply the current condition data to theone or more gig-economy data models to generate one or more gigoptimization recommendations. In some embodiments, the server 40 mayadditionally apply part of the optimization criteria to the gig-economydata models to generate the gig optimization recommendations. The gigoptimization recommendations may be generated by optimizing values ofgig metrics generated by the one or more gig-economy data models basedupon input data, which may be fixed (e.g., condition data) or variable(e.g., locations within a geographic area or type of gig-economy work).The optimized values of the gig metrics may then be used to determinerecommendations to the user in order to optimize the relevant gigmetrics.

In some embodiments, gig optimization recommendations may be based uponan optimization score calculated as a weighted combination of aplurality of gig metrics in order to account for counteracting factors.In alternative embodiments, the server 40 may generate one gigoptimization recommendation based upon the current conditions or maygenerate a plurality of gig optimization recommendations based upon thecurrent conditions.

At block 1012, in some embodiments, the server 40 may determine whetherto present one or more of the gig optimization recommendations to theuser. This may include determining a continuation estimate indicating acomparable gig metric or optimization score based upon a continuation ofcurrent gig-economy activities by the user (e.g., assuming the same typeof gig at the current location of the user). The one or more gigoptimization recommendations may be compared to the continuationestimate to determine whether at least one of the gig optimizationrecommendations improves upon the continuation estimate by a thresholdamount. Such threshold amount may be a zero or non-zero level ofimprovement, which may be expressed in terms of various metrics, such asprofit, time, risk, or rated quality.

In other embodiments, the server 40 may always present at least one gigoptimization recommendation to the user following receipt of theindication of the triggering event. Such embodiments may be implemented,for example, when a user has selected to receive such recommendations inorder to obtain the most current data for making decisions.

At block 1014, in some embodiments, the server 40 may cause arepresentation of at least one of the gig optimization recommendationsto be presented to the user via a mobile computing device 110. Therepresentation of the gig optimization recommendation may include arecommended action (e.g., changing location or gig-economy platform),which may be presented to the user as an alert or push notification. Insome embodiments, the gig optimization recommendation may furtherinclude an indication of a reason for such change (e.g., a predictedincrease in profit or decrease in risk), one or more alternativerecommendations, or a feedback option to allow the user to indicateacceptance or rejection of the gig optimization recommendation. Suchuser feedback may be used in future optimization recommendations toimprove the quality of the gig optimization recommendations for theuser.

At block 1016, in some embodiments, the server 40 may cause the gigoptimization recommendation to be implemented. This may include causingthe mobile computing device 110 to change the user's availability on oneor more gig-economy platforms (e.g., by switching between applicationsassociated with such platforms). This may similarly includecommunicating with one or more computing devices to establish theconditions for optimization of gig-economy work. For example, the server40 may communicate with one or more connected home devices 22 orautonomous devices 30 to indicate availability for gig-economy workassociated with such devices. In some embodiments, the server 40 maycause one or more autonomous devices 30 to travel to a location forgig-economy work associated with the user.

After presentation or implementation of a gig optimizationrecommendation, the real-time optimization recommendation generationmethod 1000 may end until another triggering event occurs. In someembodiments, a reset period or delay may be applied to ensure a minimumtime passes between successive gig optimization recommendations.

Exemplary Transferable Tokens for Gig-Economy Risk Assessment

Risks related to performance of gig-economy work correlate across orrelate to various categories of gig-economy activities, behaviors andwork, as well as insurance, banking, employment, security, etc., inpredictable ways. Thus, low-risk behavior in performance of one type ofgig-economy activity typically indicates low-risk behavior inperformance of gig-economy activities, behaviors and work, includingother types of gig-economy activities and work, insurance, banking,employment, security, etc. In order to increase accuracy in riskassessment for gig-economy workers and provide credit, insurance,banking, employment, etc. with lower risks, transferable tokens may begenerated for gig-economy workers and used in generation of giginsurance policies, non-gig insurance policies, banking, employment,security, etc. for such gig-economy workers.

A. Exemplary Systems for Generating and Applying Transferable Tokens forGig-Economy Risk Assessment

FIG. 11A illustrates a block diagram of an exemplary computer system1100 to generate and utilize transferable tokens 1112 for applyinginformation regarding risk across various types of gig and non-gigeconomy activities, behaviors, and work. To gather information, theexemplary system 1100 includes any number and/or type of example datacollectors, one of which is designated at reference numeral 1102. Thedata collector 1102 accesses, collects, receives, or otherwise obtainsdata 1106 from any number and/or type of data sources, one of which isdesignated at reference numeral 1104, and stores the data 1106 in acollected data database 1107. The data sources 1104 provide or makeavailable data 1106 related to gig and non-gig activities, behaviors,work, etc. In some examples, the data collector 1102 collects, accesses,or queries data 1106 from the one or more data sources 1104. In otherexamples, the data sources 1104 actively provide data 1106 (e.g.,periodically or as changed) to the data collector 1102 via, for example,an application programming interface (API) 1108.

In some examples, a gig worker 1110 (e.g., a gig-economy worker 17 ofFIGS. 1A-B) provides the data collector 1102 with permissions (e.g.,usernames, passwords, PINs, etc.) to obtain the data 1106 from the datasources 1104. In some examples, the data collector 1102 scrapes webpages for the data. In some examples, the gig workers 1110 may providedata 1106 related to themselves (which data may be gig-related ornon-gig related) via the API 1108 and/or another API (not shown).

Example data 1106 may include or relate to one or more of the followingnon-limiting examples: time spent performing gig-related activities,behaviors and work; miles driven for gig-related activities; amount ofwork per period of time; number of weeks spent performing gig-relatedactivities and work—continuous and/or total; amount of continuousgig-related activities and work; type(s) of gig-related activities andwork; payments, payment types and ratios (e.g., credit card, debit card,or online payment platforms); customer ratings or gig-related ratings;acceptance rate of gig-related activities and work; vehicle type, ageand mileage of vehicle; traditional credit information—credit score,marital status, length of employment, etc.; membership in other rewardprograms; number of financial accounts; strength of passwords; assets;contracts, mortgages, debt, bills, etc.; telematics data; drivingbehavior; motor vehicle tickets; accident record; and number and/or typeof other transactions.

To generate transferable tokens 1112, the system 1100 includes anexample token generator 1114. The token generator 1114 generates one ormore transferable tokens 1112 associated with the gig worker 1110 basedupon the data 1106 collected for the gig worker 1110. The tokens 1112are transferable in that they can, at least in some embodiments, betransferred or used by third parties or other entities on behalf of thegig worker 1110 to assist in the acquisition of further gig-relatedactivities and work, obtain financial services, insurance, etc. Forexample, a transferable token 1112 associated with a gig worker 1110indicating a good reputation for gig work performed through a firstgig-economy platform may be transferable to indicate a good generalreputation for the gig worker 1110 on a second gig-economy platform,thereby providing useful information to potential customers on thesecond gig-economy platform. The transferable tokens 1112 may include atleast one indication of a general risk level or risk preference profilefor the gig worker 1110 based upon the collected data 1106.

The token generator 1114 may generate the transferable token 1112 usingone or more risk models associated with gig performance. For example,each of a plurality of data points (e.g., gig records or event recordsassociated with gigs) of the data 1106 may be applied to a risk model todetermine risk levels associated with particular gigs or events.

Example transferable tokens 1112 may include data or entries thatrepresents, for example: reputation as a gig worker; missing data orexperience that could qualify the gig worker for a higher score orrating; financial trust and level of trust; transaction frequency;methods related to financial institutions; insurance policies andcoverages; personal and business references; personal and businessreferences; credit sources, amounts and payment history; recent lifeevents such as new job, move, marital status change, birth of child,etc.

The risk information contained in the transferable tokens 1112 may beused by one or more third parties, gig-economy customers, or other tokenconsumers, one of which is designated at reference numeral 1116, toassess reputation, quality, or risk for the gig-economy worker 1110. Thetransferable tokens 1112 may be provided to the token consumers 1116and/or accessed by the token consumer 1116 via an API 1118. Exampletoken consumers 1116 include, but are not limited to, gig-relatedservice companies (e.g., gig-economy platform operators), those seekinggig workers (e.g., gig-economy customers), those seeking non-gig workers(e.g., traditional employers), financial institutions, insuranceinstitutions, etc. In some embodiments, the risk levels or risk scoresmay be used to generate a risk modifier score indicating the gig-economyworker's general level of risk relative to a baseline (e.g., an averagerisk score for gig-economy workers in an area).

In some embodiments, such transferable tokens 1112 may be generated andstored as or with a user profile (e.g., an average mood profile orcommercial driving profile). For example, a risk modifier score may bestored as an entry in a user profile associated with the gig worker1110.

The token generator 1114 may utilize, apply, or implement amachine-learning (ML) module 1120, such as the machine-learning module54 (FIG. 1A), to adaptively learn to associate risk with gig- andnon-gig-related activities. Generally, machine-learning may involveidentifying and recognizing patterns in existing data 1106 in order tofacilitate making risk predictions for subsequent gig and non-gigactivities, behaviors and work. The ML module 1120 may be created usingunsupervised and/or supervised machine-learning.

The ML module 1120 processes gig and non-gig data 1106 stored in thecollected data database 1107 (e.g., for a first type of gig) todetermine (e.g., estimate, generate, calculate, etc.) risks associatedwith other gig-related activities, work and behaviors (e.g., for asecond type of gig). The ML module 1120 may utilize deep learningalgorithms that are primarily focused on, for example, patternrecognition, and may be trained by processing example data. The MLmodule 1120 may include Bayesian program learning (BPL), voicerecognition and synthesis, image or object recognition, opticalcharacter recognition, and/or natural language processing—eitherindividually or in combination. The ML module 1120 may also includenatural language processing, semantic analysis, and/or automaticreasoning. The ML module 1120 and/or the token generator 1114 may beimplemented by the server 40 (FIG. 1A) as a set of logical instructionsexecuted as machine- or computer-readable instructions to implement thetoken generator 1114 and/or the ML module 1120.

In some examples, the ML module 1120 is at least partially or initiallytrained using collected data 1106 for a gig worker 1110 when they wereknown not to be engaged in gig-economy activities (e.g., as indicated bythe gig worker 1110) as being unrelated to gig-economy work, such asdata 1106 provided by the gig-economy worker regarding driving prior tostarting work as a gig worker 1110. Subsequent gig and non-gigactivities could be used to further train the ML model 1120 and/or totest the ML model 1120.

In some examples, the ML model 1120 of the token generator 1114 isadditionally trained using collected data 1106 for other gig-economyworkers. Such data 1106 may be applicable, for example, when there are anumber of gig-economy worker in a same geographic area that likely havesimilar risks, gig driving patterns, etc. Such data 1106 may be used,for example, to determine an initial gig-related risk, which may befurther refined using data 1106 specific to a particular gig-economyworker.

While an exemplary system 1100 to generate and utilize transferabletokens 1112 for applying information regarding risk across various typesof gig and non-gig economy activities, behaviors, and work isillustrated in FIG. 11A, one or more of the elements, processes and/ordevices illustrated in FIG. 11A may be combined, divided, re-arranged,omitted, eliminated and/or implemented in any other way. Further, theexample data collector 1102, the example token generator 1114, theexample ML module 1120 and/or, more generally, the exemplary system 1100may be implemented by hardware, software, firmware and/or anycombination of hardware, software and/or firmware.

Thus, for example, any of the data collector 1102, the token generator1114, the ML module 1120 and/or, more generally, the system 1100 couldbe implemented by one or more analog or digital circuits, logiccircuits, programmable processors such one or more of the processor 62(FIG. 1A), programmable controller, graphics processing units (GPUs),digital signal processors (DSPs), application specific integratedcircuits (ASICs), programmable logic devices (PLDs), field programmablegate arrays (FPGAs), and/or field programmable logic devices (FPLDs).For example, the data collector 1102, the token generator 1114, the MLmodule 1120 and/or, more generally, the system 110 can be implemented asone or more modules of software, computer- or machine-readableinstructions executed on the processor 62. Further, the exemplary system1100 may include one or more elements, processes and/or devices inaddition to, or instead of, those illustrated in FIG. 11A, and/or mayinclude more than one of any or all of the illustrated elements,processes and devices.

B. Exemplary Methods for Generating and Applying Transferable Tokens forGig-Economy Risk Assessment

FIG. 11B illustrates a flow diagram of an exemplary computer-implementedmethod 1150 to generate and utilize transferable tokens 1112 forapplying information regarding risk across various types of gig andnon-gig economy activities, behaviors, and work. The method 1150 may beimplemented as one or more processes, methods, logic, software, orcomputer-readable or machine-readable instructions. The processes,methods, logic, software and instructions may be one or more executablemodules, executable programs and/or portions of an executable programfor execution by a processor such as the processor 62 of the server 40(FIG. 1A). The method 1150 may be embodied in software or instructionsstored on a non-transitory computer- or machine-readable storage device,storage medium and/or storage disk 60 associated with the processor 62in which information is stored for any non-transitory duration (e.g.,for extended time periods, permanently, for brief instances, fortemporarily buffering, and/or for caching of the information).

Although the exemplary program 1150 of FIG. 11B is described withreference to the system 1100, other methods of generating and utilizingtransferable tokens 1112 for applying information regarding risk,reputation, or quality across various types of gig and non-gig economyactivities, behaviors, and work may alternatively be implemented basedupon the description herein. For example, the order of execution of theblocks may be changed, and/or some of the blocks described may bechanged, eliminated, or combined. Additionally, or alternatively, any orall of the blocks may be implemented by one or more hardware circuits ormodules structured to perform the corresponding operations, with orwithout executing software or instructions.

The exemplary computer-implemented method 1150 of FIG. 11B forgenerating and utilizing transferable tokens 1112 for applyinginformation regarding risk across various types of gig and non-gigeconomy activities, behaviors, and work begins with, for example, thedata collector 1102 (e.g., the processor 62 of the server 40) waiting toreceive, collect or otherwise obtain data 1106 representative of currentor past gig and non-gig activities and work (e.g., a first type of gigsuch as an on-demand transportation service gigs) of the gig worker1110, and possibly other gig workers 1110 (e.g., the additionalgig-economy workers 16 of FIGS. 1A-B) (block 1152). The data 1106 may becollected as gigs are performed and/or may be collected based uponhistorical data 1106 regarding a plurality of completed gigs.

In some embodiments, the data 1106 may indicate a beginning of a new orupdated gig or non-gig related interaction between the gig worker 1110and a third party, such as, a customer (e.g., one of the gig-economycustomers 21 of FIGS. 1A-B), an insurance entity, a banking entity, etc.The data 1106 may indicate a location at which the gig worker 1110activated a gig-economy platform application on a mobile device (e.g.,the mobile computing device 110 of FIG. 2 ), a location at which the gigworker 1110 accepted a gig via a mobile device, locations to which thegig worker 1110 traveled, etc. The processor 62 may thus receive data1106 representative of one or more movements of the gig worker 1110(block 1152).

Once the data 1106 is collected, accessed, or otherwise received thetoken generator 1114 (e.g., operating on the server 40) may generate oneor more transferable tokens 1112 associated with the gig worker 1110based upon the gig and non-gig data 1106, which may relate to a currentor first type of gig and/or non-gig activities and work (block 1154).The transferable tokens 1112 may include at least one indication of arisk level or risk preference profile of the gig worker 1110 based uponthe data 1106, such as the gig metrics associated with gigs performed bythe gig worker 1110, detected gig-related behaviors (e.g., drivingbehavior) of the gig worker 1110 during performance of the gigs.

As described above, the data 1106 may, additionally and/oralternatively, include data 1106 associated with the gig worker 1110that is not gig related. In further embodiments, the transferable tokens1112 may include indications of quality or reputation, such as atransferable rating associated with the gig worker 1110 based uponperformance of one or more types of gig-economy work, which may beprovided as an indicator of likely performance of other types ofgig-economy work.

The transferable tokens 1112 may be generated using one or more riskmodels associated with gig and non-gig performance, which may be thetrained machine learning models of the ML module 1120. For example, eachof a plurality of data points (e.g., gig records or event recordsassociated with gigs and non-gig activities) of the data 1106 may beapplied to a risk model to determine risk levels associated withparticular gigs and non-gig activities (e.g., a second type of gig). Therisk levels may be used to generate one or more risk scores for the gigworker 1110, in some embodiments. In further embodiments, the risklevels or risk scores may be used to generate a risk modifier scoreindicating the gig-economy worker's general level of risk relative to abaseline (e.g., an average risk score for gig-economy workers in anarea).

In some embodiments, such transferable tokens 1112 may be generated andstored as or with a user profile (e.g., an average mood profile orcommercial driving profile). For example, a risk modifier score may bestored as an entry in a user profile associated with the gig-economyworker 1110. Such a user profile may include additional relevant datarelating to the gig worker 1110, such as the gig-related andnon-gig-related information discussed elsewhere herein with respect togig-economy workers.

In some embodiments, the token generator 1112 (e.g., the server 40) mayreceive from the gig worker 1110 or a third party (e.g., a person,organization, insurer, banker, school, or employer) associated with thegig worker 1110 a request for risk, quality, or reputation informationfor the gig worker 1110 (e.g., their transferable token 1112 orinformation based upon the transferable token 1112). The transferabletoken 1112 or information based upon the transferable token 1112 enablesthe third party to determine one or more aspects, terms, orcharacteristics of gig and non-gig activities, such as a new or updatedinsurance policy, loan approval, savings rate, admission, gig work, etc.For example, the reputation of the gig worker 1110 on other types ofgigs may be applied to a new type of gig distinct from a past or currenttypes of gigs. For example, a current type of gig may be on-demandtransportation services, while the new or updated type of gig may bepackage delivery services.

Although the risks associated with the two types of gigs may bedifferent, the information regarding risk levels may be applicable toboth. Thus, the server 40 may determine a risk level associated with theupdated or new type of gig(s) based in part upon the risk levelsassociated with the current type of gig as indicated by the transferabletoken 1112 (block 1158).

In some embodiments, this may include using one or more risk models suchas the ML module 1120 to generate risk levels based upon condition data,gig-economy worker profile data, or other available data 1106 regardingperformance of gigs of the new or updated types of gigs by the gigworker 1110, then adjusting such risk levels by a factor determined fromthe transferable token 1112. In some such embodiments, a risk modifiermay be directly applied to the calculated risks associated with the newor updated type of gig to determine adjusted risk levels. In someexamples, the transferable token 1112 itself is provided to a requestingthird party to make risk assessments or other determinations based upontheir own criteria in addition to and/or alternative to any risk scoreincluded in the transferable token 1112.

Based upon the adjusted risk levels determined using the transferabletoken 1114, the server 40 may then generate or update gig or non-gigactivities (block 1160). For example, a gig insurance policy covering atleast the new or updated gig or non-gig activities may be updated orgenerated. In some embodiments, indications or options regarding the giginsurance policy may be presented to the gig worker 1110 via a display202 of a mobile computing device 110 (FIG. 2 ). In further embodiments,the generated or updated data may include data regarding a predictionrelating to the gig worker 1110 in a new activity, such as performing anew type of gig-economy work with high quality or timely repaying a newloan.

The transferable token generation and application method 1150 may thenend. In some embodiments, further data 1106 may be collected regardingperformance of new or updated gig and non-gig activities used to refinethe risk levels indicated in the transferable token 1112, which may beapplied to further types of gigs.

Exemplary Targeted Recommendation Generation for Gigs

During the performance of gig-economy work, gig-economy workers orcustomers may benefit from certain additional services, products, orofferings by other parties. However, the variety of additional services,products, or offerings may be overwhelming. Therefore, targetedrecommendations may be generated and presented to gig-economy workers orcustomers based upon data associated with such gig-economy workers orcustomers to improve the value of such recommendations.

FIG. 12A illustrates a flow diagram of an exemplary targetedrecommendation method 1200 for generating and presenting recommendationsfor a particular gig-economy worker. Although the method 1200 describesgenerating and presenting such recommendations to a gig-economy worker,it should be understood that a similar method may be used to generateand present recommendations to customers within the gig economy. Themethod 1200 may be performed in whole or part by the processors 62 ofone or more servers 40 in communication within one or more mobilecomputing devices 110 or other computing devices. In furtherembodiments, similar methods may be implemented including additional,fewer, or alternative aspects.

The targeted recommendation method 1200 may begin with the server 40receiving an indication of ongoing gig-economy work by a gig-economyworker (block 1202). The indication may be associated with performanceof a particular gig or may simply indicate availability for gig-economywork. The indication may be generated by an application on a user mobiledevice 12 or other mobile computing device 110 associated with thegig-economy worker 17 upon occurrence of an event (e.g., acceptance of agig, completion of a gig, or indication of availability on a gig-economyplatform application) and communicated to the server 40 via the network3. Upon receiving the indication, the server 40 may access a profileassociated with the gig-economy worker (block 1204). The profile mayinclude information related to past gigs performed, gig data related tosuch gigs, previous recommendations presented to the gig-economy worker,preferences of the gig-economy worker (e.g., risk preference, preferredwork schedule, or loyalty rewards program memberships), or otherrelevant data associated with the gig-economy worker. The profile may beaccessed from a database 46 associated with the server 40.

In some embodiments, the server 40 may additionally obtain currentcondition data associated with the gig-economy work (block 1206). Suchcurrent condition data may include current conditions relating to acurrent or expected future location of the gig-economy worker.

The server 40 then generates one or more targeted recommendations forthe gig-economy worker based upon the available information (block1208), which may include the profile and/or the current condition data.In some embodiments, the recommendations may be generated using one ormore recommendation models associated with gig-economy work, which maybe trained machine learning models similar to those discussed elsewhereherein. The one or more recommendations generated may includerecommendations regarding gig insurance policies, fuel, food, coffee,tools, equipment, supplies, or similar products or services.

The recommendations may include discounts or special offers for thegig-economy worker. For example, the server 40 may determine a vehicle10 is running low on fuel based upon current condition data receivedfrom an on-board computer 11A and generate a recommendation to refuel ata nearby gas station, which may further include a promotional code toreceive a discount on a car wash. In some embodiments, the one or morerecommendations may be generated by or based upon data provided byadditional participants 51 (e.g., local businesses or aggregatedadvertising platforms) via additional participant computing devices 50in communication with the server 40 via the network 3.

After the one or more recommendations have been generated for thegig-economy worker, the server 40 may cause the recommendations to bepresented to the gig-economy worker (block 1210). Causing the one ormore recommendations to be presented may include sending data containingsuch recommendations to a mobile computing device 110 associated withthe gig-economy worker to cause the presentation of the one or morerecommendations via a display 202. In some embodiments, therecommendations may be displayed together with one or more options toobtain further information or to implement a recommendation (e.g., bypurchasing a gig insurance policy or obtaining directions to alocation). The targeted recommendation method 1200 may then end.

A. Exemplary Systems and Related Functionality for Facilitating TargetedRecommendation Display for Transportation Network Trips

FIG. 12B illustrates an exemplary computer system 1211 for facilitatingtargeted recommendation display for transportation network trips. Theexemplary system 1211 may include a vehicle 1212, an electronic display1213, an electronic device 1214, an external processing server 1215, amessage provider device 1216, external databases 1217, and a network1218. While illustrated in FIG. 12B as a single external database, insome embodiments the external databases 1217 includes two or moreexternal databases. The network 1218 may be a computer network of aninsurance provider (e.g., provided or used by the insurance provider orcommunications over which the insurance provider otherwise controls orfacilitates).

In reference to the exemplary system 1220 of FIG. 12C, the electronicdevice 1214 may include the electronic display 1213, a processor 1222, amemory 1224, a transceiver 1226, and an imaging sensor 1228. Whilereferred to herein as a “processor” and a “memory,” in some embodimentsthe processor 1222 includes two or more processors and the memory 1224includes two or more memories. The processor 1222 may be configured toanalyze both still image data and video data (e.g., video data receivedby the transceiver 1226) and analyze aspects of the still image dataand/or video data. The memory 1224 may store computer-executableinstructions, which may be executed by the processor 1222.

It should be understood that the electronic display 1213 may be eitheran external, standalone device or an internal component of theelectronic device 1214. In other words, in certain embodiments, theelectronic display 1213 may be a standalone entity disposed within avehicle (e.g., vehicle 1212). In that case, the electronic display 1213may have a processor, memory, imaging assembly, transceiver, etc., andbe configured to receive a targeted recommendation from the electronicdevice 1214, external processing server 1215, or any other suitabletransmitter (e.g., external databases 1217).

The imaging sensor 1228 may include, for example, an image sensor (e.g.,a camera, a video camera), and/or a proximity sensor. As such, theimaging sensor 1228 may be configured to capture still images, videofootage, proximity information (e.g., indicative of distances to/fromimaging apparatus). However, it should be understood that the imagingsensor 1228 is not limited to the sensors disclosed herein.Additionally, the electronic device 1214 may be configured to receivecommunications from the external processing server 1215 and/or othersuitable transmitters (e.g., external databases 1217) in response totransmitting captured data and/or before, during, or after displaying atargeted message.

The external processing server 1215 may include a database 1230, aprocessor 1232, a memory 1234, and a transceiver 1236. While referred toherein as a “processor” and a “memory,” in some embodiments theprocessor 1232 includes two or more processors and the memory 1234includes two or more memories. The processor 1232 may be configured toprocess both still image data and video data (e.g., video data receivedfrom a prospective client) and analyze aspects of the still image dataand/or video data. The memory 1234 may store computer-executableinstructions, which may be executed by the processor 1232. The database1230 may include gig-economy worker profiles.

The gig-economy worker profiles may correspond to a set of informationassociating a gig-economy worker with certain transportation networktrip characteristics and/or priorities. For example, a gig-economyworker profile may indicate that a particular gig-economy worker (e.g.,driving vehicle 1212) may consistently drive in low population densityareas, and may further drive in those areas late at night. As furtherdiscussed herein, based upon the gig-economy worker profile, theexternal processing server 1215 may determine targeted recommendationsfor display on the electronic display 1213. The gig-economy workerprofiles may also correspond with insured user profiles/accounts,insurance policies, or other user profiles, accounts, policies, etc.

Further, the gig-economy worker profile may include relevant dataassociated with a gig-economy worker indicated in the gig-economy workerprofile. For example, if a gig-economy worker profile includesinformation associated with an insurance policy listing a gig-economyworker as the insured, the insurance policy may list the gig-economyworker's name, age, gender, etc. Moreover, and as discussed furtherherein, the relevant data may include multiple profile featuresassociated with each gig-economy worker profile. These profile featuresmay, for example and as discussed further herein, facilitate targetedrecommendation display within a vehicle 1212 by allowing the externalprocessing server 1215 to develop a broader knowledge base with which todetermine the targeted recommendations for display.

The exemplary computer system 1220 further includes a message providerdevice 1216. The message provider device 1216 includes a messagedatabase 1238, a processor 1240, a memory 1242, and a transceiver 1244.While referred to herein as a “processor” and a “memory,” in someembodiments the processor 1240 includes two or more processors and thememory 1242 includes two or more memories. The message database 1238 mayinclude a set of recommendations for display, for example, on theelectronic display 1213 disposed within the vehicle 1212 for viewing bya gig-economy worker and/or a customer of the gig-economy worker.

The message provider device 1216 may be connected to each of theelectronic device 1214 and the external processing server 1215 via thenetwork 1218, such that all devices (1214, 1215, and 1216) maycommunicate to each other via their respective transceivers (1226, 1236,and 1244). For example, the external processing server 1215 may receiveupdated gig-economy worker profile information from the electronicdevice 1214. The external processing server 1215 may store this receivedinformation in its database 1230 and/or its memory 1234. Thus, and asdiscussed further herein, the external processing server 1215 may beconfigured to process, analyze, or otherwise interpret data captured byand/or received from the electronic device 1214.

Moreover, the message provider device 1216 may transmit targetedrecommendation data to the electronic device 1214 and/or externalprocessing server 1215 through the network 1218. The electronic device1214 and/or external processing server 1215 may receive the targetedrecommendation and store it in memory 1224, 1234 and/or further transmitthe targeted message to the electronic device 1214 and/or electronicdisplay 1213 for display. It will be appreciated that the externalprocessing server 1215 and/or message provider device 1216 may be aserver and/or device provided by or used by an insurance provider, oruse of which the insurance provider otherwise controls or facilitates.

In some embodiments, the network 1218 may be or may include a networksuch as the Internet and/or any other type of suitable network (e.g., alocal area network (LAN), a metropolitan area network (MAN), a wide areanetwork (WAN), a mobile network, a wired or wireless network, a privatenetwork, a virtual private network, etc.). The network 1218 may also oralternatively be or include one or more cellular networks such as codedivision multiple access (CDMA) network, GSM (Global System for MobileCommunications) network, WiMAX (Worldwide Interoperability for MicrowaveAccess) network, Long Term Evolution (LTE) network, etc.

As further described below, the exemplary systems (1211, 1220)facilitate targeted recommendation display within automobiles, andallow, among other advantages, convenient, incentivized recommendationsto gig-economy workers and/or their customers to increase revenue forgig-economy workers and customers alike. The recommendations displayedon the systems described herein are more readable than those ofconventional digital displays because the recommendations are displayedwithin vehicles which places the recommendations closer to gig-economyworkers and/or customers than the conventional display devices (e.g.,billboards).

The recommendations are also more relevant than the static, generalmessages on conventional display devices because they are dynamicallyupdated and targeted for the gig-economy worker and/or customer, and canbe based upon travel routes extracted from the gig-economy applications.Moreover, the systems of the present disclosure improve userinteractions with targeted recommendations by allowing a gig-economyworker and/or customer to potentially generate revenue during agig-economy trip (e.g., a transportation network trip) by interactingwith the targeted recommendations.

B. Exemplary Methods for Facilitating Targeted Recommendation Displayfor Transportation Network Trips

FIG. 12D is a flowchart depicting an exemplary computer-implementedmethod 1250 corresponding to various embodiments of the presentdisclosure. The method 1250 begins at block 1252 where, for example, acomputer processor (e.g., electronic device 1214) receives availabilitydata corresponding to a gig-economy worker and environmental dataassociated with an environment of a vehicle (e.g., vehicle 1212). Theavailability data may indicate a beginning of a commercial interactionbetween the gig-economy worker and a customer (e.g., gig-economycustomers 21). However, it should be understood that the availabilitydata may indicate a gig-economy worker activating a gig application on amobile device and/or any other suitable action or combination thereof.For example, the gig-economy worker may activate a gig application on amobile computing device (e.g., mobile computing device 110) to initiateparticipation in the gig-economy system 100. By activating the mobileapplication, the mobile computing device may transmit the availabilitydata to an external server (e.g., fleet management server 45) tofacilitate the gig-economy worker matching with a customer, as describedherein.

Moreover, the availability data may include profile information relatingto the gig-economy worker and/or a customer who accepts a gig with thegig-economy worker. The profile information included in the availabilitydata may generally relate to any activity taken by the gig-economyworker and/or customer on gig applications. For example, in someembodiments, the availability data may include a gig-economy workerpurchasing history or a customer purchasing history. Block 1252 may beperformed by, for example, the electronic device 1214.

The environment may be an area located proximate to and/or extendingaway from the vehicle 1212. For example, the environment may be orinclude a street, highway, interstate, sidewalks, crosswalks, frontlawns, parking lots, etc. Moreover, the environment and theenvironmental data may include a current route traveled by thegig-economy worker during a gig. For example, the environmental data mayindicate a set of individuals and landmarks associated with theenvironment of the vehicle 1212, and entities/situations likely to beencountered on the current route (e.g., traffic conditions along thecurrent route). In some embodiments the environmental data may includeone or more of: (i) a road condition, (ii) a weather condition, (iii) anearby traffic condition, (iv) a road type, (v) a constructioncondition, (vi) a presence of pedestrians, or (vii) a presence of otherobstacles.

In some embodiments, the computer processor (e.g., electronic device1214) may receive the environmental data from one or more of (i)vehicle-to-vehicle (V2V) communication protocols, (ii)vehicle-to-infrastructure (V2I) communication protocols, or (iii) one ormore mobile devices. For example, the computer processor maycommunicate, via the transceiver 1226, with other vehicles to determineenvironmental data concerning another vehicle and its occupants. Thecomputer processor may receive environmental data such as the year,make, model, VIN of another vehicle, and/or any associated userinformation linked with the vehicle data. As one example, theenvironmental data received from another vehicle may be associated witha gig-economy worker profile of the driver of the other vehicle. Thevehicle 1212 may access this gig-economy worker profile and extractother information from the profile that may be relevant. The profile mayindicate, inter alia, number of gigs completed, typical drivingpatterns/locations, length of average gig, ratings received in gigapplications, targeted recommendations displayed and/or interacted with,and/or any other suitable information or combination thereof. Asdiscussed further herein, the external processing server 1215 mayreceive and use such information when determining a targetedrecommendation for display on the electronic display 1213.

In certain embodiments, detecting the environmental data may furtherinclude capturing the environmental data via the imaging sensor 1228.The imaging sensor 1228 may include an image sensor, and the imagesensor may be configured to capture a set of digital images. The set ofdigital images may be included in or otherwise comprise theenvironmental data. Generally, the electronic device 1214 includes afield of view (FOV) indicating an area where the electronic device's1214 sensors (e.g., imaging sensor 1228) are capable of capturing data(e.g., environmental data). In certain embodiments, the vehicle 1212 mayhave a sensor or sensors surrounding its exterior and thus may have aneffective FOV corresponding to the entire surrounding environment of thevehicle or any portion of the surrounding environment therein.

Moreover, and as discussed further herein, the FOV may have a range ofany suitable degree to capture the necessary environmental data. Forexample, the electronic device's 1214 sensors may be disposed at aplurality of locations around the vehicle 1212 such that the entireenvironment (e.g., 360° view surrounding the vehicle 1212) is capturedto yield environmental data.

To illustrate, the imaging sensor 1228 may capture a set of digitalimages featuring a set of individuals and landmarks associated with theenvironment of the vehicle 1212. The imaging sensor 1228 may capture theset of digital images in response to receiving the availability data orotherwise confirming the gig-economy worker's participation in a gig,and/or in response to the proximity sensor or any other sensor includedin the imaging sensor 1228 detecting the presence of at least one entitywithin a FOV of the imaging sensor 1228.

The imaging sensor 1228 may also include a proximity sensor, and theproximity sensor may be configured to capture a set of proximity data.The proximity data may be indicative of a set of distances from thevehicle 1212 to individuals, landmarks, and/or other entities within thevehicle 1212 environment. To illustrate, the proximity sensor maycapture a set of proximity data indicative of a set of distances fromthe vehicle 1212 for each of a set of landmarks (e.g., buildings withinviewing distance of the vehicle 1212). The proximity sensor may furtherdetermine that a restaurant is 20 feet from the vehicle 1212, a clothingstore is 50 feet from the vehicle 1212, a gas station is 100 feet fromthe vehicle 1212, etc. Additionally, the proximity sensor may determinethat the restaurant is 20 feet from the right rear panel of the vehicle1212, the clothing store is 50 feet from the left rear panel of thevehicle 1212, etc.

In certain embodiments, the electronic device 1214 may transmit, via thetransceiver 1226, the set of distances and the set of digital images tothe external processing server 1215. As discussed further herein, theexternal processing server 1215 may then determine the targetedrecommendation by correlating the set of distances with the set ofdigital images. For example, the external processing server 1215 mayprioritize recommendations that are more relevant to the landmarks thatare closer to the vehicle 1212, and thus, the electronic device 1214.

After the electronic device 1214 captures the environmental data, thedevice 1214 may analyze the environmental data to determine theindividuals, landmarks, and/or other entities included therein. Theseindividuals, landmarks, and/or other entities may be categorized andtransmitted to the external processing server 1215 or a targetedrecommendation model stored in memory 1224 to determine a targetedrecommendation. The computer processor may use any of a number ofextraction techniques to generate the demographic data from theenvironmental data.

The computer processor may include (i) facial recognition, (ii) objectrecognition (OR), (iii) optical character recognition (OCR), and/or anyother suitable extraction technique. Moreover, the computer processormay incorporate other relevant features into the environmental data. Forexample, the computer processor may include a location of the vehicle, atime when the image sensor captured the set of digital images, weatherconditions included in the images (e.g., snow, rain, fog, etc.), and/orany other suitable features or combination thereof.

The method 1250 continues at optional block 1254 by determining whethera user is available to receive a targeted recommendation based upon theavailability data. Generally, if a gig-economy worker or customer doesnot have a gig application active, they may be unavailable to receive atargeted recommendation. If the gig-economy worker or customer has a gigapplication active, but has not currently accepted/requested a gig, orhas recently completed a gig, they may be available to receive atargeted recommendation. However, if the gig-economy worker is currentlyperforming a gig (e.g., driving a customer to a destination), then thegig application may be active, but the gig-economy worker may beunavailable for a targeted recommendation. Accordingly, the electronicdevice (e.g., electronic device 1214) executing the gig application maydetermine whether a gig-economy worker and/or customer is available toreceive a targeted recommendation based upon the availability data, forexample, by determining whether the gig-economy worker is activelyperforming a gig.

If the availability data indicates the vehicle is moving along a routespecified by the gig application (e.g., from point A to the customer'sdestination), then the electronic device may determine that thegig-economy worker is unavailable to receive a targeted recommendation.Similarly, if the availability data corresponding to a customerindicates that the customer recently completed a gig (e.g., reachedtheir destination), then the electronic device may determine that thecustomer is unavailable to receive a targeted recommendation. Optionalblock 1254 may be performed by, for example, the electronic device 1214.

Additionally or alternatively, the availability data may includeinformation a gig application provider or platform provider may use tovet and qualify gig-economy workers. For example, the availability datamay include accident information, telematics information, and/or othersuitable information to indicate whether a gig-economy worker qualifiesto receive/display and/or profit from targeted recommendations.

The targeted recommendation platform may include multiple tiers oftargeted recommendations which may include different vendors and/ormessages and may further include different qualifications based upon theavailability data. For example, a first vendor may submit three distincttargeted recommendations for display within a gig-economy workervehicle.

The first targeted recommendation may be included in a first tier of thetargeted recommendation platform, may include a first message, may havea relatively small profit share with the gig-economy worker, and mayrequire a low level of qualification (e.g., below average reviews, belowaverage time spent working via gig application, etc.) to display. Thesecond targeted recommendation may be included in a second tier of thetargeted recommendation platform, may include a second message, may havea relatively average profit share with the gig-economy worker, and mayrequire a medium level of qualification (e.g., average reviews, averagetime spent working via gig application, etc.) to display. The thirdtargeted recommendation may be included in a third tier of the targetedrecommendation platform, may include a third message, may have arelatively large profit share with the gig-economy worker, and mayrequire a high level of qualification (e.g., above average reviews,above average time spent working via gig application, etc.) to display

The method 1250 continues at block 1256 by determining a targetedrecommendation based upon the environmental data and the availabilitydata. Generally, a targeted recommendation may be a message from aparticipating vendor or other entity that is intended to provide theviewer with relevant information for that viewer. For example, incertain embodiments, the targeted recommendation may include (i) asurvey, (ii) a coupon, (iii) a special offer, and/or (iv) anadvertisement. Block 1256 may be performed by, for example, theelectronic device 1214.

The computer processor may determine the targeted recommendation basedupon a stored selection of recommendations (e.g., stored in database1230 and/or message database 1238), the computer processor may receive atargeted recommendation from an external source (e.g., message providerdevice 1216), the computer processor may retrieve a relevantrecommendation from an external source (e.g., external databases 1217),and/or the computer processor may generate a targeted recommendationbased upon a targeted recommendation model (e.g., stored in memory1224). The targeted recommendations may include surveys, advertisements,coupons, interactive video/audio displays, videos, audio recordings,and/or any other suitable data or combination thereof.

For example, the computer processor may analyze the environmental datato determine a set of tags representative of a set of landmarksindicated in the environmental data. This set of tags may include datacorresponding to any of the information indicated herein, includingvehicle location, time of day, weather, building location, logos, streetsign text, geolocation data, and/or any other suitable environmentalindication. Using this set of tags, the computer processor may determinea targeted message by applying a targeted recommendation model to theset of tags.

The targeted recommendation model may utilize machine learning, such asa convolutional neural network or any other suitable machine learningarchitecture. For example, the targeted recommendation model mayassociate the set of tags included in the environmental data with thecorresponding tags included in each of a stored set of messages. Thestored message that includes the most tags corresponding with the set oftags included in the environmental data may be selected for display.

To illustrate, assume the computer processor (e.g., electronic device1214) generates environmental data indicative of a set of landmarksadjacent to a roadway which a gig-economy worker is activelytransporting a customer along a route planned by the correspondinggig-economy application. As mentioned, the electronic device 1214 maygenerate this environmental data through use of mapping/geolocationtechnology accessed through the gig-economy application platform,through the use of on-board sensors (e.g., imaging sensor 1228), throughthe access to gig-economy worker profiles and customer profiles, and/orany other suitable source. Thus, further assume that the computerprocessor accesses profiles for both the gig-economy worker and thecustomer to retrieve customer profile data and gig-economy workerprofile data.

In this example, the environmental data may indicate that the set oflandmarks includes a grocery store, a gas station, a clothing store, anda fast food restaurant; and the customer profile data may indicate thatthe customer has taken several trips to the clothing store whileutilizing the services of a gig-economy worker. The computer processormay utilize the targeted recommendation model to determine that atargeted recommendation regarding a coupon for the clothing store shouldbe displayed to the customer. If a targeted recommendation correspondingto the clothing store exists in memory (e.g., memory 1224) or can beretrieved from an external source (e.g., message database 1238), thenthe computer processor may simply display the targeted recommendation tothe customer via the electronic display 1213 disposed in the vehicle1212.

However, if a targeted recommendation corresponding to the clothingstore does not exist in memory, the targeted recommendation is outdated,or the computer processor cannot otherwise simply retrieve a targetedrecommendation, the computer processor may utilize the targetedrecommendation model to generate a targeted recommendation. For example,if the computer processor accesses, via the network 1218, a website orother database corresponding to the clothing store, the computerprocessor may retrieve relevant information about the clothing store toinclude in the targeted recommendation. The computer processor mayretrieve the clothing store hours, address, sales/deals informationassociated with the particular store location identified in theenvironmental data, and/or any other suitable data. Accordingly, thecomputer processor may extract the time of day from a timestamp of theenvironmental data to determine whether the clothing store is open, andwhether any potential sales/deals identified from the store website orother suitable source are available to the customer. Assuming that thecustomer is passing or approaching the clothing store during businesshours and while a sale/deal is currently ongoing, the computer processormay automatically generate, via the targeted recommendation model, atargeted recommendation for the customer indicating the currentsale/deal at the clothing store (e.g., “50% off all items at X clothingstore,” etc.)

Moreover, in this example, the computer processor may generate a surveystyle targeted recommendation for the customer based upon their profileinformation (e.g., purchasing history, travel locations, etc.). Thecomputer processor may utilize the targeted recommendation model togenerate a survey/questionnaire regarding the types of clothing (e.g.,clothing brands, apparel types, etc.) a customer may prefer or prefer tolearn more about. The computer processor may access the clothing storewebsite to extract various brands, clothing types, and/or other relevantinformation from the website to generate a survey containing topics onwhich the customer may vote or otherwise express an opinion or interest.For example, the computer processor, using the targeted recommendationmodel, may generate a survey style targeted recommendation asking thecustomer which popular brands of clothing the customer may be interestedin purchasing, learning more about, receiving discounts for, beingnotified of sales, etc. The survey may also ask the customer about typesof clothing the user is interested in purchasing, after which, thecomputer processor may provide brand recommendations that cater to theclothing types the customer indicated.

In certain embodiments, the computer processor (e.g., electronic device1214, external processing server 1215) determines the targetedrecommendation by correlating the set of distances captured by theproximity sensor with the set of digital images captured by the imagesensor. For example, the set of digital images may indicate a set oflandmarks displaced at various distances from the vehicle 1212, as willbe correspondingly indicated in the set of distances. The computerprocessor may, in part, determine the targeted recommendation bydetermining a message that is more relevant to the landmarks with asmaller associated distance in the set of distances.

To illustrate, assume there are two landmarks included in theenvironmental data. The first landmark is a clothing store located nearan upcoming exit ramp of an interstate highway that is part of a routefor a customer of a gig-economy worker. The second landmark is a gasstation near a subsequent exit ramp of the interstate highway that isbeyond the route for the customer (e.g., further along the interstateand past the customer's exit). The computer processor may search fortargeted recommendations for both landmarks, but may prioritize atargeted recommendation for the clothing store. The clothing store isalong the route of the customer, and thus increases the chance thecustomer will take advantage of the targeted recommendation, and the gasstation may be of minimal interest to the customer because they are notcurrently driving a vehicle (e.g., vehicle 1212) that would utilize agas station. The computer processor may analyze the distances in the setof distances to make this determination, and correspondingly weight theremaining data associated with the clothing store more heavily than thedata associated with the gas station when making the targetedrecommendation determination. Accordingly, the computer processor maydetermine a targeted recommendation that is relevant to some and/or alllandmarks identified in the environmental data, but that is morerelevant to the closer landmarks or those landmarks that are nearby thecurrent route of a customer.

In certain embodiments, determining the targeted recommendationcomprises transmitting the environmental data to an external processingserver (e.g., external processing server 1215). Once the externalprocessing server 1215 receives the transmitted environmental data, theserver 108 may determine the targeted recommendation from theenvironmental data, and transmit the targeted recommendation to theelectronic device 1214.

The method 1250 continues at block 1258 by displaying the targetedrecommendation on an electronic display disposed within the vehicle(e.g., vehicle 1212). Generally, and as previously mentioned, theelectronic display (e.g., electronic display 1213) may be an interactiveinterface of the vehicle, an electronic device of the gig-economyworker, and/or an electronic device of the customer. For example, theelectronic display 1213 may be disposed on the back of a head restwithin the vehicle 1212, or the computer processor may display thetargeted recommendation via a customer's electronic device through thegig-economy application. In certain embodiments, the electronic displaymay be non-interactive, and may present discount/sale/deal informationthe customer or gig-economy worker may read from the electronic display,scannable codes (e.g., QR codes), and/or other information which theuser is unable to access or influence by touching, swiping, or otherwisephysically interacting with the electronic display. Block 1258 may beperformed by, for example, the electronic display 1213.

As mentioned herein, in certain embodiments, the electronic display 1213and the electronic device 1214 may be communicatively connected, butphysically separate elements. For example, the electronic device 1214may be located in the vehicle 1212 interior (e.g., as a connectedcomponent of the engine control unit (ECU)), while the electronicdisplay 1213 is disposed within the vehicle 1212. Accordingly, incertain embodiments where the electronic device 1214 and the electronicdisplay 1213 are physically separate elements, if the electronic device1214 determines the targeted recommendation, the electronic device 1214may transmit the targeted recommendation to the electronic display 1213to display the targeted recommendation for viewing by the gig-economyworker, the customer, and/or any other suitable recipient. Thegig-economy worker, the customer, and/or other suitable recipient mayview the targeted recommendation, and may receive the message containedtherein, interact with the targeted recommendation, and/or perform othersuitable actions in accordance with the particular targetedrecommendation displayed.

In certain embodiments, prior to displaying a targeted recommendation,the computer processor may display an opt-in option for viewing by acustomer, gig-economy worker, and/or other suitable recipient.Generally, the opt-in option may indicate to the customer that they havean option to receive targeted recommendations based upon their routes,historical usage of gig-economy applications, customer profileinformation, and other suitable information. For example, a customer mayinitiate a gig-economy application to ride from point A to point B.Shortly after being picked up at point A, the gig-economy applicationmay prompt the customer to either opt-in or opt-out of receivingtargeted recommendations.

If the customer opts-out of receiving targeted recommendations, thecomputer processor may refrain from receiving environmental data,determining a targeted recommendation, and displaying the targetedrecommendation for the duration of the current gig from point A to pointB. If the customer opts-in to receiving targeted recommendations, thecomputer processor may immediately or at any point during the currentgig from point A to point B receive environmental data, determine atargeted recommendation, and display the targeted recommendation to thecustomer.

Moreover, in certain embodiments, the targeted recommendations mayindicate an amount of expected revenue the customer, gig-economy worker,and/or other suitable recipient may receive as a result of receiving thetargeted recommendations. Generally, the targeted recommendations mayprovide a customer or gig-economy worker an opportunity to generatepersonal revenue by answering questions (e.g., in a survey typerecommendation) or by otherwise interacting with the targetedrecommendations (e.g., scanning a displayed QR code).

The computer processor may calculate or otherwise access a revenueamount associated with each targeted recommendation, and include therevenue amount before, during, or after displaying the targetedrecommendation. For example, the computer processor may display to acustomer a topic for a survey type targeted recommendation, along withan associated revenue the customer may earn as a result of completingthe survey type targeted recommendation. Once the customer completes thesurvey type targeted recommendation, the computer processor mayauthorize a transfer of funds in the amount of the associated revenuefrom an account associated with the survey type targeted recommendationto an account associated with the customer.

In certain embodiments, and responsive to causing the electronic displayto display the targeted recommendation, determining one or more of (i) abenefit or (ii) an incentive associated with a policy associated withthe gig-economy worker. Generally speaking, a gig-economy worker and/ora customer may receive targeted recommendations during a gig as a meansto generate more personal revenue. Gig-economy workers may interact withthe electronic display to acknowledge targeted recommendations whilewaiting for a customer to arrive or in between gigs, but a gig-economyworker may be unable to interact with the electronic display whiledriving. Accordingly, when a gig-economy worker has a gig-applicationactive, the computer processor may preferentially offer the gig-economyworker targeted recommendations when the gig-economy worker is notactively performing a gig. If the computer processor determines that thegig-economy worker acknowledges the targeted recommendation while notperforming a gig, the computer processor may also determine that thegig-economy worker should receive a beneficial impact to theirassociated policy (e.g., a gig policy).

Correspondingly, the computer processor may transmit a notification tothe external processing server 1215 indicating the intended benefit(e.g., lower premium, lower deductible, elevated coverage level, etc.).The external processing server 1215 may then access the insurance policyand apply the benefit to the insurance policy. In this way, the system(1211, 1220) facilitates both targeted recommendation display for thosewithin the vehicle 1212, and an improved insurance incentive programwhereby users (e.g., insurance customers) have increased satisfactionthrough lower insurance rates and higher levels of service.

The method 1250 continues at block 1260 by receiving a user response tothe targeted recommendation. Generally, the user response may include agig-economy worker and/or a customer interacting with the display toselect responses to questions, scanning the display to receive ascannable code or other message displayed thereon, and/or any othersuitable response. For example, the targeted recommendation may be asurvey-type, wherein the user response may include a series of responsesto questions posed in succession on the electronic display.

If the electronic display is interactive, the user response may includethe gig-economy worker and/or customer touching, swiping, gesturing,reading aloud, and/or otherwise interacting with the electronic display.If the electronic display is non-interactive, the user response mayinclude the gig-economy worker and/or customer capturing one or moreimages of the display, scanning the display, and/or otherwise extractingthe information contained in the targeted recommendation. Block 1260 maybe performed by, for example, the electronic device 1214.

The method 1250 continues at block 1262 by implementing an action basedupon the user response to the targeted recommendation. Once the user(e.g., gig-economy worker and/or customer) provides a user response tothe targeted recommendation, the electronic device may transmit the userresponse to an external computing device (e.g., the external processingserver 1215, the message provider device 1216, etc.) where the userresponse may be processed. Based upon the information contained in theuser response, the external computing device may determine and implementa corresponding action. Block 1262 may be performed by, for example, theprocessor 1222, the external processing server 1215, and/or the messageprovider device 1216.

Generally speaking, the corresponding action may indicate an interactionwith a user profile, a signal to a vendor website/platform, and/or anyother suitable action configured to acknowledge the user response. Forexample, a customer may complete a survey-type targeted recommendationand interact with the user interface to indicate the completion of thesurvey. The computer processor may transmit the indication of thecompleted survey to a vendor server that is managed by a vendor thatsponsored the survey to inform the vendor server of the user thatcompleted the survey. The indication may include user profileinformation corresponding to the customer, and as a result, the vendorserver may perform an action by transmitting/applying a discount relatedto goods/services provided by the vendor to the user profilecorresponding to the customer. Moreover, the action may correspond tothe message provider device 1216 or other suitable device/processorinitiating a transfer of funds from a message provider account to anaccount associated with the customer.

In certain embodiments, the action may correspond to a benefit appliedto an insurance policy (e.g., a gig policy), such as a lower premium, alower deductible, a broader coverage base, a higher policy limit, etc.However, it will be appreciated that the action may be any suitable typeof benefit application, incentive receipt, and/or other suitableresponse or combination thereof.

In certain embodiments, and responsive to receiving the user responsefrom the customer or gig-economy worker, the computer processor maydetermine a follow-up question/series of questions, and/or submit thereceived response information to a vendor, sponsor, or other suitableentity. For example, if a targeted recommendation provides a customer orgig-economy worker with a discount code for a fast food restaurant inthe form of a QR code, the customer may scan the QR code with asmartphone or other suitable device. The smartphone may then transmit areceipt signal through the gig-economy application to acknowledgereceipt of the targeted recommendation. The computer processor may thentransmit the acknowledgement to a server/database or other suitableresource associated with the fast food restaurant to indicate that theirdiscount code is being scanned as a result of the targetedrecommendations.

Additionally or alternatively, the computer processor may record theacknowledgement for use in future determinations of targetedrecommendations. For example, the computer processor may prioritizetargeted recommendations associated with the fast food restaurant, fastfood restaurants, food related recommendations, and/or any suitablecategorization or combination thereof.

Accordingly, the method 1250 continues at block 1264 by recording theuser response for determination of future targeted recommendations.Generally, the external processing server 1215 or a targetedrecommendation model stored in memory 1224 used to determine a targetedrecommendation may receive the user response, and store the response inmemory to inform future targeted recommendations. The externalprocessing server 1215 and/or the targeted recommendation model mayextract individual responses/interactions and user profile data from theuser response to determine correlations between responses given and usercharacteristics. Block 1264 may be performed by, for example, the memory1224, the external processing server 1215, and/or the message providerdevice 1216.

For example, if a user response indicates that a young customerresponded to a survey-type targeted recommendation related to a firstclothing store, the external processing server 1215 and/or the targetedrecommendation model may preferentially display a similar/identicalsurvey-type targeted recommendation related to the first clothing storeto other young customers.

Moreover, the external processing server 1215 and/or the targetedrecommendation model may analyze individual responses within the userresponse to determine correlations that are user-specific. For example,if a gig-economy worker completes a survey-type targeted recommendationrelated to fast food restaurants, the external processing server 1215and/or the targeted recommendation model may analyze each response todetermine fast food preferences of the gig-economy worker. Thegig-economy worker may indicate that they prefer a first fast foodrestaurant over a second fast food restaurant. Accordingly, the externalprocessing server 1215 and/or the targeted recommendation model maypreferentially display future targeted recommendations corresponding tothe first fast food restaurant for the gig-economy worker.

As will be apparent from the above description, and as should beappreciated with respect to all examples presented herein, the functionsor operations shown in FIG. 12D may be performed in any suitable order,any desired number of times, and/or with any suitable variation to theparticular order and/or combination shown so as to achieve a desiredresult, such as a desired manner of facilitating targeted recommendationdisplay within gig-economy vehicles.

By providing systems and methods that facilitate targeted recommendationdisplay within gig-economy vehicles as described herein, variousadvantages are achieved. For example, the systems and methods provideand/or are implemented through the use of devices that provideinformation particularly suited for use with other features of thesystems and methods to facilitate targeted recommendation display withingig-economy vehicles. Notably, the systems and methods provide aseamless, real-time solution to detecting environmental data associatedwith an environment of a vehicle, determining a targeted recommendationfrom the environmental data, and displaying the targeted recommendation.The targeted recommendations are more relevant than the static, generalmessages on conventional display devices because they are dynamicallyupdated, targeted, and generated/determined for the gig-economy workerand/or customer.

The systems and methods of the present disclosure can generate targetedrecommendations based upon travel routes extracted from the gig-economyapplications and profile information associated with the gig-economyworker and/or customer. Moreover, the systems of the present disclosureimprove user interactions with targeted recommendations by allowing agig-economy worker and/or customer to potentially generate revenueduring a gig-economy trip (e.g., a transportation network trip) byinteracting with the targeted recommendations. Other advantages will berecognized by one of ordinary skill in the art in light of the teachingand disclosure herein.

Exemplary Gig-Economy Services Coordination and Mobilization

At any given time, only a small portion of all gig-economy workers areengaged in gig-economy activities or indicate themselves as availablefor gig-economy work. Some portion of the remaining gig-economy workerswould be available to accept new gigs if they knew such gigs to beavailable, but they may be logged out of the relevant gig-economyplatform applications or may have silenced notifications relating to gigdemand. During emergencies, such as natural disasters, there may be anurgent need for certain gig-economy services such as on-demandtransportation. Likewise, non-emergency situations may createirregularly occurring or non-recurring intervals of elevated demand forgig-economy services, which may be local to areas associated withtriggering events.

For example, a large corporate event, political or civic event, orentertainment event may result in an interval of high demand foron-demand transportation services in an area near the event. Similarly,a powerful storm system may subsequently result in an interval of highdemand for gig-economy work related to repair of water damage, roofdamage, or damage to landscaping elements.

FIG. 13 illustrates a flow diagram of an exemplary coordination andmobilization method 1300 for providing gig-economy services togig-economy service consumers during times of elevated demand. Suchmethods may be implemented by a server 40 of a gig-economy servicecoordinator (e.g., an insurer or third party) to facilitate provisionsof gig-economy services to gig-economy service consumers. Thegig-economy service consumers may be gig-economy customers 21 (orassociated customer computing devices 20) who obtain the performance ofgig-economy services, but who may or may not directly pay for suchservices.

The coordination and mobilization methods may be used to coordinategig-economy workers and gig-economy service consumers for gigs duringtransient intervals of high demand relative to supply of gig-economyservices. For example, to coordinate performance of gig-economy servicesduring times of elevated demand, the server 40 may be further configuredto communicate with gig-economy platforms (e.g., on-demand servicesnetwork platforms 70) to match or otherwise facilitate gigs forgig-economy workers and gig-economy service consumers. In someembodiments, this may include providing discount codes to gig-economyservice consumers or providing incentives to gig-economy workers.

In further embodiments, the methods may involve mobilization ofgig-economy workers to meet high demand caused by triggering events. Asan example, to accommodate elevated demand, the server 40 may be furtherconfigured to determine the occurrence of a triggering event (e.g., anobserved spike in demand or an event expected to significantly increasedemand in the immediate future), identify a plurality of currentlyinactive gig-economy workers (e.g., gig-economy workers who aresigned-out of a gig-economy platform or scheduled as unavailable forgig-economy work but not currently performing a gig) based upon userprofiles indicating past performance of relevant types of gigs, andcause alert notifications to be sent to the identified gig-economyworkers (e.g., by communication with a gig-economy platform server or bydirect communication with a plurality of mobile computing devices 110associated with the identified gig-economy workers). In someembodiments, the alert notifications may include details regarding thegig demand, such as causes of the increased demand, expected duration ofthe increased demand, or locations of the increased demand. In furtherembodiments, similar methods may be implemented including additional,fewer, or alternative aspects.

The exemplary coordination and mobilization method 1300 may begin withmonitoring event data concerning potential triggering events (block1302). The event data may be evaluated to determine the occurrence of atriggering event associated with elevated demand for gig-economy service(block 1304). In some embodiments, gig-economy service consumersassociated with the triggering event (e.g., gig-economy customerslocated in an affected area) may be identified (block 1306). Parametersassociated with the elevated demand may also be determined (block 1308),such as demand quantity, duration, or location. From such parameters, ademand profile may then be generated (block 1310) and communicated toone or more gig-economy platforms in order to obtain availability dataassociated with the availability of gig-economy workers to meet theelevated demand (block 1312). In some embodiments, the method mayinclude determining whether the elevated demand exceeds the availabilityof the gig-economy workers (block 1314) and, if so, sending alerts toinactive gig-economy workers to notify them of the elevated demand(block 1316). Performance of gig-economy service is coordinated via theone or more gig-economy platforms (block 1318), which may includeconnecting gig-economy workers with gig-economy service consumers orotherwise facilitating payment or incentives for relevant gigs.

At block 1302, the server 40 may monitor event data relating totriggering events associated with elevated levels of demand forgig-economy services. Such event data may include data regardingemergency conditions, natural disasters, severe weather, largegatherings, or other similar triggering events. The event data mayinclude data regarding triggering events that have already occurred(e.g., past severe weather conditions), are presently occurring (e.g.,evacuation due to emergency conditions in an area), or are scheduled tooccur at a future time (e.g., planned entertainment, civic, charitable,or other events). Monitoring event data may include evaluating data atthe server 40, collecting data from external data sources, or receivinga notification from a party associated with a triggering event.

In some embodiments, a party associated with a planned future event(e.g., an event organizer) may provide event data to the server 40 viathe network 3 as an indication of the future event (e.g., a notificationor request to coordinate gig-economy services related to the event),which event data may be provided in a format accepted by applicationprogramming interfaces (APIs) of the server 40. In further embodiments,the server 40 may request or receive notifications regarding emergencyconditions, such as severe weather alerts, emergency reports, or otherdata regarding events for which gig-economy services may be required.

In some embodiments, the server 40 may receive data from one or moreexternal data sources providing data regarding events via the network 3,which may include current events or future events. Such external datasources may include data streams or sites, from which the server 40 maycontinuously or periodically collect event data. In some embodiments,the event data may be manually entered by an operator via an API of theserver 40.

At block 1304, the server 40 may determine the occurrence of atriggering event associated with an elevated demand level over a limitedinterval of time based upon the event data. An indication of thetriggering event may be generated based upon patterns identified orinferred from the event data (e.g., by identifying a type of eventlikely to cause a spike in demand for a type of gig-economy service), oran indication of the triggering event may be directly extracted from theevent data (e.g., by extracting the indication from a notification orrequest of the triggering event provided to the server 40). Triggeringevents may include emergency conditions causing an elevated demand forgig-economy services, unscheduled events causing an elevated demand forgig-economy services, or scheduled events causing an elevated demand forgig-economy services.

Emergency conditions and unscheduled events may include hurricanes,fires, floods, other natural disasters, outbreaks of disease, chemicalspills, civil unrest, or other similar conditions creating an elevateddemand for related gig-economy services in areas associated with thetriggering event. For example, natural disasters may be associated withan elevated demand for on-demand transportation services, followed by anelevated demand for repair services. Scheduled events may includeprivate or public events organized by groups, entities, or individuals,such as company meetings, conferences, marathons, or concerts.

In some embodiments, determining the occurrence of a triggering eventmay include the determination of information associated with thetriggering event, such as parameters relating to an associated area, anassociated time, or a plurality of associated gig-economy serviceconsumers. In some embodiments, determining the occurrence of thetriggering event may include determining an upcoming interval ofelevated demand associated with a current or future triggering event.For example, a scheduled future gathering or anticipated future severeweather conditions may be identified as triggering events occurringwithin projected time intervals.

Other triggering events may be determined to have occurred in the pastyet cause an elevated demand for certain gig-economy services in thepresent or future. For example, a past emergency condition in an areamay be determined to have occurred, causing property damage within anassociated area. In such example, repair or maintenance gig-economyservices may experience elevated demand after the emergency conditionhas passed.

At block 1306, in some embodiments, the server 40 may identify aplurality of gig-economy service consumers associated with thetriggering event. The gig-economy service consumers may be gig-economycustomers 21 (or associated customer computing devices 20) that are insome way associated with the triggering event. An association may bedetermined between the gig-economy service consumers and an areaassociated with the triggering event, such as by proximity to a locationof the triggering event. As an example, the gig-economy serviceconsumers may be identified as individuals currently located in orassociated with an address within an area affected by the triggeringevent, such as individuals in an area being evacuated due to anemergency condition (e.g., hurricane, earthquake, fire, flooding, orchemical hazards). In some such embodiments, the server 40 may identifythe gig-economy service consumers based upon geospatial coordinates fromGPS units 250 of mobile computing devices 110 associated with thegig-economy service consumers. In some such embodiments, current orfrequent locations of a predefined set of potential gig-economy serviceconsumers may be determined and used to identify the gig-economy serviceconsumers associated with an area of the triggering event, such aslocations of individuals having accounts with the gig-economy servicecoordinator (e.g., home addresses of customers of an insurer).

An association may similarly be determined between the gig-economyservice consumers and a party associated with the event, such as anorganizer of a large gathering. As an example, employees of a company orvolunteers of a charity event may be identified as gig-economy serviceconsumers by organizations organizing large events. Such gig-economyservice consumers may be identified by an organizer or other partyassociated with the triggering event in a notification or request sentto the gig-economy service coordinator.

In some embodiments, the gig-economy service consumers may be identifiedbased upon other associations with a triggering event, such as insurancecustomers of an insurer who have filed claims related to property damage(e.g., flooding, roof damage, damaged trees, broken windows, orstructural damage) following severe weather conditions.

At block 1308, the server 40 may determine parameters associated withthe elevated demand for gig-economy services based upon the obtained ordetermined information. Such parameters may be determined based upon theevent data or other data, including information regarding the triggeringevent, information from external data sources, information regardingidentified gig-economy service consumers, or information provided in arequest or notification to the gig-economy service coordinator (e.g.,expected attendance at scheduled events). The parameters may indicateinformation relevant to the provisioning of gig-economy services, suchas the following: one or more types of gig-economy services associatedwith the elevated demand, a demand quantity for the one or more types ofgig-economy services (e.g., a level of total demand or incrementalincrease in demand), one or more times or intervals of time associatedwith the elevated demand (e.g., a time window during which demand isexpected to be elevated), one or more areas or locations associated withthe triggering event or with the elevated demand, one or more details ofthe gig-economy service demand (e.g., transportation distance, repaircompletion timing, or access limitations), one or more requirements forperformance of the gig-economy services (e.g., equipment required,skills required, or minimum quality rating required), one or more priceor cost levels associated with the gig-economy services, one or morepriority levels associated with the elevated demand, or one or moreincentives associated with performance of the gig-economy services.

The types of gig-economy services may include on-demand transportationservices (e.g., transportation from an area impacted by emergencyconditions, transportation to a scheduled event, or transportation froma scheduled event), repair or maintenance services (e.g., repair ofproperty damage following severe weather, flooding, fire, or civilunrest), business support services (e.g., short-term logistics ordelivery support), or other gig-economy services. The demand quantitymay be an estimate of current demand associated with the triggeringevent or an estimate of future demand associated with a futuretriggering event (e.g., a scheduled corporate event, charitable activityevent, political or civic event, or entertainment event).

At block 1310, the server 40 may generate a demand profile based uponthe determined parameters. The demand profile may include indications ofthe parameters, such as actual or estimated demand quantity for a typeof gig-economy service related to the triggering event. The demandprofile may include additional relevant information related to theelevated demand, such as timing information or other informationincluding or related to the determined parameters. In some embodiments,the demand profile may include indications of one or more gig-economyplatforms for use in coordination or mobilization of gig-economy serviceperformance, as discussed below. In further embodiments, the demandprofile may be formatted in a manner for communication to the one ormore gig-economy platforms.

At block 1312, the server 40 may communicate demand data with one ormore gig-economy platforms to obtain availability data relating togig-economy worker availability to perform the one or more types ofgig-economy services. The demand data may be sent from the server 40 toAPIs of the one or more gig-economy platforms via the network 3 torequest or collect availability data, and responses including theavailability data may be received by the server 40 via the network 3. Insome embodiments, the server 40 may communicate with a fleet managementserver 45 or other server associated with each of the one or moregig-economy platforms to obtain the availability data.

The demand data may include the demand profile, data extracted from thedemand profile, or data otherwise associated with the demand profile.Such demand data may indicate values of the parameters determined by theserver 40, such as demand quantity. If the elevated demand is expectedto occur at a future time, the demand data may further include anindication of the time or time interval associated with the demandquantity.

In response to communicating the demand data to the one or moregig-economy platforms, the server 40 may receive the availability dataregarding availability of a plurality of gig-economy workers associatedwith the respective one or more gig-economy platforms. In order toprovide more useful information, the availability data may be limited togig-economy workers who match the parameters associated with theelevated demand, such as gig-economy workers performing one or moretypes of gig-economy services indicated in the demand data. Theavailability data may indicate overall availability of the plurality ofgig-economy workers, without specifically indicating availability ofspecific workers. Alternatively, the availability data may indicatecurrent, scheduled, or predicted availability of specific gig-economyworkers. In some embodiments, availability data may be obtained by theserver 40 from the one or more gig-economy platforms via associated APIsbased upon parameters associated with time and location (and, whereapplicable, type of gig-economy service), without sending an indicationof a demand quantity.

At block 1314, in some embodiments, the server 40 may use theavailability data and the demand profile to determine whether the actualor estimated level of the elevated demand exceeds the availability ofgig-economy workers to perform the gig-economy services. Suchdetermination may be based upon the total demand and total availability,or it may be based upon the incremental demand above ordinary levelsassociated with the triggering event.

In some such embodiments, the server 40 may further determine one ormore responses to the disequilibrium between the supply and demand ofthe gig-economy services, such as taking actions to increaseavailability or decrease demand. Increasing the supply of availablegig-economy workers to perform the gig-economy services for thegig-economy service consumers may include alerting inactive gig-economyworkers to the elevated demand, providing incentives to the gig-economyworkers to perform the gig-economy services, or providing incentives tothe one or more gig-economy platforms to prioritize the gig-economyconsumers over other gig-economy customers. Decreasing the demand mayinclude prioritizing a subset of gig-economy consumers for priorityperformance of gig-economy services (e.g., scheduling waves or groups ofgig-economy consumers at different times), offering incentives togig-economy service consumers to delay receiving gig-economy services,or adding disincentives for gig-economy service consumers.

At block 1316, in some embodiments, the server 40 may coordinateperformance of gig-economy services by sending alerts or notificationsto inactive gig-economy workers to increase availability of gig-economyworkers to perform the gig-economy services associated with thetriggering event. The alerts or notifications may be generated by theserver 40 and transmitted to the inactive gig-economy workers (eitherdirectly or through the respective one or more gig-economy platforms) toindicate the elevated level of demand.

In some embodiments, such alerts or notifications may further indicateincentives to perform the gig-economy services. Such incentives mayinclude bonus payments or other inducements to perform the type ofgig-economy services associated with the elevated demand for thegig-economy service consumers, which may be the identified gig-economyservice consumers. As an example, the server 40 may identify a pluralityof inactive gig-economy workers providing on-demand transportationservices based upon previous registration of the workers with thegig-economy coordinator or with respective gig-economy platforms toreceive notifications of emergency demand or other elevated demandsituations, which may include determining inactive gig-economy workerproximity to an area affected by the elevated demand based upongeospatial location data, then send alert notification to the identifiedinactive gig-economy workers. Thus, the inactive gig-economy workers maybe notified of unexpected situations of elevated demand, such asemergency evacuation conditions.

At block 1318, the server 40 may coordinate performance of gig-economyservices according to the determined parameters by the gig-economyworkers for the gig-economy service consumers via the one or moregig-economy platforms. In some embodiments, such coordination mayinclude obtaining performance of the gig-economy services throughmultiple gig-economy platforms, which may offer the same type ofgig-economy services or different types of gig-economy services. Thus,in some embodiments, the server 40 may coordinate performance of onetype of gig-economy service for the plurality of gig-economy serviceconsumers by facilitating performance for some of the gig-economyservice consumers through a first gig-economy platform and for othergig-economy service consumers through a second gig-economy platform(e.g., by assigning the individual gig-economy service consumers todifferent gig-economy platforms). In some embodiments, it may not benecessary, possible, or desirable to obtain performance for thegig-economy services for all of the gig-economy service consumers, sothe server 40 may coordinate performance to the gig-economy services foronly some of the gig-economy service consumers (e.g., the identifiedgig-economy service consumers).

Coordination of the performance of the gig-economy services may includeconnecting individually identified gig-economy service consumers withspecific gig-economy workers through the APIs of the one or moregig-economy platforms. In some embodiments, such coordination mayinclude providing user discount codes for the gig-economy services tothe gig-economy service consumers. Such user discount codes may beobtained from the gig-economy platforms through their APIs (or providedto the gig-economy platforms through their APIs) to provide partial orfull reductions in the cost of the gig-economy services provided to thegig-economy service consumers. The server 40 may obtain or generate userdiscount codes and provide such codes to the gig-economy serviceconsumers (e.g., via e-mail, text message, or application notificationon a mobile computing device of each identified gig-economy serviceconsumer) for use in obtaining performance of the gig-economy services.The gig-economy service consumers may then enter such user discountcodes into applications associated with the gig-economy platforms whenobtaining the gig-economy services.

In some embodiments, similar codes may be provided to and used by thegig-economy service consumers to obtain priority performance of thegig-economy services, with or without a discount or surcharge. Infurther embodiments, coordinating performance of the gig-economyservices may include providing incentives to the gig-economy workers forperforming the gig-economy services for the gig-economy serviceconsumers. Such incentives may include bonus payments to gig-economyservices provided according to the determined parameters associated withthe elevated demand, which bonus payments may be variable based uponaspects of such performance (e.g., based upon timing of performance,distance of travel, or other metrics of performance). In some suchembodiments, the server 40 may provide indications of such incentives tothe gig-economy workers via APIs of the gig-economy platforms, whichindications may be tied to user codes or may be presented to thegig-economy workers via mobile applications related to the respectivegig-economy platforms. Other methods of coordinating performance of thegig-economy services may additionally or alternatively be implemented invarious embodiments.

Other Matters

Although the preceding text sets forth a detailed description ofnumerous different embodiments, it should be understood that the legalscope of the invention is defined by the words of the claims set forthat the end of this patent. The detailed description is to be construedas exemplary only and does not describe every possible embodiment, asdescribing every possible embodiment would be impractical, if notimpossible. One could implement numerous alternate embodiments, usingeither current technology or technology developed after the filing dateof this patent, which would still fall within the scope of the claims.

It should also be understood that, unless a term is expressly defined inthis patent using the sentence “As used herein, the term ‘ ’ is herebydefined to mean . . . ” or a similar sentence, there is no intent tolimit the meaning of that term, either expressly or by implication,beyond its plain or ordinary meaning, and such term should not beinterpreted to be limited in scope based upon any statement made in anysection of this patent (other than the language of the claims). To theextent that any term recited in the claims at the end of this patent isreferred to in this patent in a manner consistent with a single meaning,that is done for sake of clarity only so as to not confuse the reader,and it is not intended that such claim term be limited, by implicationor otherwise, to that single meaning.

With the foregoing, an insurance customer may opt in to a program toreceive a reward, insurance discount, or other type of benefit. In someaspects, customers may opt in to a rewards, loyalty, or other programassociated with gig-economy work monitoring, such as a rewards programthat collects data regarding user driving in order to determinediscounts for safe driving behavior. The customers may therefore allow aremote server to collect sensor, telematics, vehicle, mobile device, andother types of data discussed herein. With customer permission oraffirmative consent, the data collected may be analyzed to providecertain benefits to customers. For instance, insurance cost savings maybe provided to lower risk or risk averse customers. Recommendations thatlower risk or provide cost savings to customers may also be generatedand provided to customers based upon data analysis, as discussedelsewhere herein. Other functionality or benefits of the systems andmethods discussed herein may also be provided to customers in return forthem allowing collection and analysis of the types of data discussedherein. In return for providing access to data, risk-averse insureds,vehicle owners, or vehicle occupants may receive discounts or insurancecost savings on transportation-related insurance, as well as home,renters, personal articles, and other types of insurance from theinsurance provider.

Throughout this specification, plural instances may implementcomponents, operations, or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. Structures andfunctionality presented as separate components in example configurationsmay be implemented as a combined structure or component. Similarly,structures and functionality presented as a single component may beimplemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

Additionally, certain embodiments are described herein as includinglogic or a number of routines, subroutines, applications, orinstructions. These may constitute either software (code embodied on anon-transitory, tangible machine-readable medium) or hardware. Inhardware, the routines, etc., are tangible units capable of performingcertain operations and may be configured or arranged in a certainmanner. In example embodiments, one or more computer systems (e.g., astandalone, client or server computer system) or one or more modules ofa computer system (e.g., a processor or a group of processors) may beconfigured by software (e.g., an application or application portion) asa module that operates to perform certain operations as describedherein.

In various embodiments, a module may be implemented mechanically orelectronically. For example, a module may comprise dedicated circuitryor logic that is permanently configured (e.g., as a special-purposeprocessor, such as a field programmable gate array (FPGA) or anapplication-specific integrated circuit (ASIC) to perform certainoperations. A module may also comprise programmable logic or circuitry(e.g., as encompassed within a general-purpose processor or otherprogrammable processor) that is temporarily configured by software toperform certain operations. It will be appreciated that the decision toimplement a module mechanically, in dedicated and permanently configuredcircuitry, or in temporarily configured circuitry (e.g., configured bysoftware) may be driven by cost and time considerations.

Accordingly, the term “module” should be understood to encompass atangible entity, be that an entity that is physically constructed,permanently configured (e.g., hardwired), or temporarily configured(e.g., programmed) to operate in a certain manner or to perform certainoperations described herein. Considering embodiments in which modulesare temporarily configured (e.g., programmed), each of the modules neednot be configured or instantiated at any one instance in time. Forexample, where the modules comprise a general-purpose processorconfigured using software, the general-purpose processor may beconfigured as respective different modules at different times. Softwaremay accordingly configure a processor, for example, to constitute aparticular module at one instance of time and to constitute a differentmodule at a different instance of time.

Modules can provide information to, and receive information from, othermodules. Accordingly, the described modules may be regarded as beingcommunicatively coupled. Where multiple such modules existcontemporaneously, communications may be achieved through signaltransmission (e.g., over appropriate circuits and buses) that connectthe modules. In certain embodiments in which multiple modules areconfigured or instantiated at different times, communications betweensuch modules may be achieved, for example, through the storage andretrieval of information in memory structures to which the multiplemodules have access. For example, one module may perform an operationand store the output of that operation in a memory device to which it iscommunicatively coupled. A further module may then, at a later time,access the memory device to retrieve and process the stored output.Modules may also initiate communications with input or output devices,and may operate on a resource (e.g., a collection of information).

The various operations of exemplary methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or more processors orprocessor-implemented modules. The performance of certain of theoperations may be distributed among the one or more processors, not onlyresiding within a single machine, but deployed across a number ofmachines. In some example embodiments, the one or more processors orprocessor-implemented modules may be located in a single geographiclocation (e.g., at a location of a mobile computing device or at aserver farm). In other example embodiments, the one or more processorsor processor-implemented modules may be distributed across a number ofgeographic locations.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation. Such memories may be or may include non-transitory,tangible computer-readable media configured to store computer-readableinstructions that may be executed by one or more processors of one ormore computer systems.

As used herein any reference to “one embodiment,” “an embodiment,” “oneexample,” or “an example” means that a particular element, feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment. The appearances of the phrases“in one embodiment,” “in an embodiment,” “in some embodiments,” “in oneexample,” “in some examples,” or similar phrases in various places inthe specification are not necessarily all referring to the sameembodiment, the same example, or the same set of embodiments orexamples.

Some embodiments may be described using the terms “coupled,”“connected,” “communicatively connected,” or “communicatively coupled,”along with their derivatives. These terms may refer to a direct physicalconnection or to an indirect (physical or communicative) connection. Forexample, some embodiments may be described using the term “coupled” toindicate that two or more elements are in direct physical or electricalcontact. The term “coupled,” however, may also mean that two or moreelements are not in direct contact with each other, but yet stillco-operate or interact with each other. Unless expressly stated orrequired by the context of their use, the embodiments are not limited todirect connection.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the description. Thisdescription, and the claims that follow, should be read to include oneor at least one and the singular also includes the plural unless thecontext clearly indicates otherwise.

This detailed description is to be construed as exemplary only and doesnot describe every possible embodiment, as describing every possibleembodiment would be impractical, if not impossible. One could implementnumerous alternate embodiments, using either current technology ortechnology developed after the filing date of this application.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for thesystems and a methods disclosed herein. Thus, while particularembodiments and applications have been illustrated and described, it isto be understood that the disclosed embodiments are not limited to theprecise construction and components disclosed herein. Variousmodifications, changes and variations, which will be apparent to thoseskilled in the art, may be made in the arrangement, operation anddetails of the method and apparatus disclosed herein without departingfrom the spirit and scope defined in the appended claims.

The particular features, structures, or characteristics of any specificembodiment may be combined in any suitable manner and in any suitablecombination with one or more other embodiments, including the use ofselected features without corresponding use of other features. Inaddition, many modifications may be made to adapt a particularapplication, situation or material to the essential scope and spirit ofthe present invention. It is to be understood that other variations andmodifications of the embodiments of the present invention described andillustrated herein are possible in light of the teachings herein and areto be considered part of the spirit and scope of the present invention.

Finally, the claims at the end of this patent are not intended to beconstrued under 35 U.S.C. § 112(f), unless traditionalmeans-plus-function language is expressly recited, such as “means for”or “step for” language being explicitly recited in the claims. Thesystems and methods described herein are directed to an improvement tocomputer functionality, which may include improving the functioning ofconventional computers in performing tasks.

What is claimed is:
 1. A computer-implemented method for automaticallyclassifying driving activity by a gig-economy worker, the methodcomprising: obtaining, by one or more processors, telematics dataassociated with operation of one or more vehicles by the gig-economyworker, wherein the telematics data comprises at least speed andlocation data for a plurality of trip segments corresponding torespective times and road segments of the plurality of trip segments;generating, by a classifier executed by the one or more processors, alikelihood score for each of the plurality of trip segments based uponthe telematics data associated with such trip segment, wherein thelikelihood score indicates a probability or probability range of therespective trip segment being a gig-related trip segment associated withgig driving activities by the gig-economy worker; classifying, by theclassifier executed by the one or more processors, each of the pluralityof trip segments as being a gig-related trip segment or anon-gig-related trip segment based upon the respective likelihood score;and identifying, by the one or more processors, one or more gig-relatedtrips comprising a plurality of gig-related trip segments.
 2. Thecomputer-implemented method of claim 1, wherein obtaining the telematicsdata comprises controlling a plurality of sensors disposed within theone or more vehicles to record periodic measurements of the telematicsdata.
 3. The computer-implemented method of claim 1, further comprising:obtaining, by the one or more processors, environmental data regardingan operating environment of the respective vehicle for each of theplurality of trip segments, wherein the likelihood score for each of theplurality of trip segments is determined based upon the telematics dataand the environmental data associated with such trip segment.
 4. Thecomputer-implemented method of claim 1, wherein the likelihood score foreach of the plurality of trip segments is based at least in part uponcomparison of the telematics data associated with the respective tripsegment with a baseline profile of non-gig-related driving by thegig-economy worker.
 5. The computer-implemented method of claim 1,wherein generating the likelihood score for each of the plurality oftrip segments comprises processing the telematics data associated withthe respective trip segment using a machine learning model previouslytrained on additional telematics data associated with a plurality ofadditional trip segments including both gig-related driving andnon-gig-related driving by the gig-economy worker.
 6. Thecomputer-implemented method of claim 5, where in the machine learningmodel has been previously validated using log data from a gig-economyplatform indicating a definitive classification of at least some of theadditional trip segments.
 7. The computer-implemented method of claim 1,wherein identifying the one or more gig-related trips comprisesidentifying a current trip is gig-related.
 8. The computer-implementedmethod of claim 1, wherein identifying the one or more gig-related tripscomprises identifying one or more sets of multiple gig-related tripsegments separated by one or more sets of non-gig-related trip segments.9. The computer-implemented method of claim 1, further comprising:determining, by the one or more processors, an aspect of an insurancepolicy for the gig-economy worker based upon the telematics dataassociated with the gig-related trip segments of the one or moregig-related trips, wherein the aspect of the insurance policy associatedwith the gig-economy worker includes at least one of type of insurance,an insurance premium, a deductible, an insured limit, or a condition.10. A system for automatically classifying driving activity by agig-economy worker, comprising: one or more processors; and anon-transitory computer-readable storage medium storingcomputer-readable instructions that, when executed by the one or moreprocessors, cause the system to: obtain telematics data associated withoperation of one or more vehicles by the gig-economy worker, wherein thetelematics data comprises at least speed and location data for aplurality of trip segments corresponding to respective times and roadsegments of the plurality of trip segments; generate a likelihood scorefor each of the plurality of trip segments based upon the telematicsdata associated with such trip segment, wherein the likelihood scoreindicates a probability or probability range of the respective tripsegment being a gig-related trip segment associated with gig drivingactivities by the gig-economy worker; classify each of the plurality oftrip segments as being a gig-related trip segment or a non-gig-relatedtrip segment based upon the respective likelihood score; and identifyone or more gig-related trips comprising a plurality of gig-related tripsegments.
 11. The system of claim 10, wherein the computer-readableinstructions that cause the system to obtain the telematics data causethe system to control a plurality of sensors disposed within the one ormore vehicles to record periodic measurements of the telematics data.12. The system of claim 10, wherein the likelihood score for each of theplurality of trip segments is based at least in part upon comparison ofthe telematics data associated with the respective trip segment with abaseline profile of non-gig-related driving by the gig-economy worker.13. The system of claim 10, wherein the computer-readable instructionsthat cause the system to generate the likelihood score for each of theplurality of trip segments cause the system to process the telematicsdata associated with the respective trip segment using a machinelearning model previously trained on additional telematics dataassociated with a plurality of additional trip segments including bothgig-related driving and non-gig-related driving by the gig-economyworker.
 14. The system of claim 10, wherein the computer-readableinstructions, when executed by the one or more processors, further causethe system to: determine an aspect of an insurance policy for thegig-economy worker based upon the telematics data associated with thegig-related trip segments of the one or more gig-related trips, whereinthe aspect of the insurance policy associated with the gig-economyworker includes at least one of type of insurance, an insurance premium,a deductible, an insured limit, or a condition.
 15. A tangible,non-transitory computer-readable medium storing computer-readableinstructions that, when executed by one or more processors of a system,cause the system to: obtain telematics data associated with operation ofone or more vehicles by the gig-economy worker, wherein the telematicsdata comprises at least speed and location data for a plurality of tripsegments corresponding to respective times and road segments of theplurality of trip segments; generate a likelihood score for each of theplurality of trip segments based upon the telematics data associatedwith such trip segment, wherein the likelihood score indicates aprobability or probability range of the respective trip segment being agig-related trip segment associated with gig driving activities by thegig-economy worker; classify each of the plurality of trip segments asbeing a gig-related trip segment or a non-gig-related trip segment basedupon the respective likelihood score; and identify one or moregig-related trips comprising a plurality of gig-related trip segments.16. The tangible, non-transitory computer-readable medium of claim 15,wherein the computer-readable instructions that cause the system toobtain the telematics data cause the system to control a plurality ofsensors disposed within the one or more vehicles to record periodicmeasurements of the telematics data.
 17. The tangible, non-transitorycomputer-readable medium of claim 15, wherein: the computer-readableinstructions, when executed by the one or more processors, further causethe system to obtain environmental data regarding an operatingenvironment of the respective vehicle for each of the plurality of tripsegments; and the likelihood score for each of the plurality of tripsegments is determined based upon the telematics data and theenvironmental data associated with such trip segment.
 18. The tangible,non-transitory computer-readable medium of claim 15, wherein thelikelihood score for each of the plurality of trip segments is based atleast in part upon comparison of the telematics data associated with therespective trip segment with a baseline profile of non-gig-relateddriving by the gig-economy worker.
 19. The tangible, non-transitorycomputer-readable medium of claim 15, wherein the computer-readableinstructions that cause the system to generate the likelihood score foreach of the plurality of trip segments cause the system to process thetelematics data associated with the respective trip segment using amachine learning model previously trained on additional telematics dataassociated with a plurality of additional trip segments including bothgig-related driving and non-gig-related driving by the gig-economyworker.
 20. The tangible, non-transitory computer-readable medium ofclaim 15, wherein the computer-readable instructions, when executed bythe one or more processors, further cause the system to: determine anaspect of an insurance policy for the gig-economy worker based upon thetelematics data associated with the gig-related trip segments of the oneor more gig-related trips, wherein the aspect of the insurance policyassociated with the gig-economy worker includes at least one of type ofinsurance, an insurance premium, a deductible, an insured limit, or acondition.